Rebaseline test fast/forms/date/date-suggestion-picker-appearance.html
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=platform%2Fchromium%2Ffast%2Fforms%2Fdate%2Fdate-suggestion-picker-appearance-rtl.html It appears that the text cursor is sometimes shown and sometimes hidden. Seems like a race condition. I thought we had code in DRT to explicitly make it so the cursor didn't blink and was instead always visible.
Ryosuke pointed me at FrameSelection::setCaretBlinkingSuspended. But that can be called by non-DRT code to set the caret blinking again. I think we need a method in Settings that disables caret blinking and makes the caret always be visible.
that's a fun source of flakiness, alright.
Created attachment 166569 [details] Patch
Comment on attachment 166569 [details] Patch Thanks for working on this! I was picturing that we'd change this setting from DumpRenderTree for all tests. I can't think of any test where we'd want caret blinking to be enabled. Any test that doesn't set this and has a caret will be flaky, no?
If the number of setCaretBlinkingSuspended(true) calls and the number of setCaretBlinkingSuspended(false) calls are matched, we had better make FrameSelection::m_isCaretBlinkingSuspended an integer, and change the code so that setCaretBlinkingSuspended(true) increases the integer, setCaretBlinkingSuspended(false) decreases the integer, isCaretBlinkingSuspended() returns true if the integer is <= 0.
I think we should first make sure that our conjuncture about the bug is correct.
(In reply to comment #7) > I think we should first make sure that our conjuncture about the bug is correct. What is there to verify other than the clear results in the pixel output (i.e. sometimes it passes and other times it fails with a missing caret)?
(In reply to comment #8) > (In reply to comment #7) > > I think we should first make sure that our conjuncture about the bug is correct. > > What is there to verify other than the clear results in the pixel output (i.e. sometimes it passes and other times it fails with a missing caret)? I think we should at least verify that FrameSelection::setCaretBlinkingSuspended is what DRT uses to stop the blinks, and that there is some call to setCaretBlinkingSuspended during this test (with a race) that causes the test to fail sometimes. In particular, it'll be really nice if we learn what the races are.
As best I can tell, we were wrong when we thought DRT did something to control caret blinking. I couldn't find any code that did. It does not call setCaretBlinkingSuspended. So the race seems straightforward if I'm not mistaken. It's just that the caret is blinking.
(In reply to comment #10) > As best I can tell, we were wrong when we thought DRT did something to control caret blinking. I couldn't find any code that did. It does not call setCaretBlinkingSuspended. So the race seems straightforward if I'm not mistaken. It's just that the caret is blinking. That was my conclusion too.
Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests.