Revert in pipe as crrev.com/c/1244830, PTAL. 

I doubt that the CL is related to the observed flakiness:
- The CL fixes an oob read (reading past the end of a string).
- The test seems unrelated to the CL.
- The flakiness mode is weird here - the test went from "always *failing*" to "flakily passing".

Can we hold off with the revert and either
1) re-run FindIt's analysis (possibly asking it to either A) run more iterations at each revision or B) run iterations at each of the revisions between r590405 and r590411 (or possibly slightly wider) or
2) disable the test instead (especially since it is under a virtual test suite, so I assume it tests a Blink feature that is not yet enabled by default).

I'll take the sheriff label off, it'll get re-added if it detects another flake.

I agree with lukasza@.  The CL in question fixes logic that shouldn't be invoked in this layout test.  Also note that the test is already marked as flaky in TestExpectations, referencing issues 874162 and 827209, so I think this bug should be duped into one of those.  Reassigning to sunyunjia@, owner of the latter bug, to confirm.

The flake is matching [ Pass Failure ] on Win,Linux so this is probably a timeout issue rather than an explicit failure as a flake.

Sorry misread these[1] instructions, first time sheriff here, re-adding the Sheriff-Chromium label.

[1] http://dev.chromium.org/developers/tree-sheriffs/sheriffing-bug-queues

webkit_layout_tests are marked experimental, removing sheriff label.

Yunjia, please have a look at the flake or help assign a more suitable owner.