Bug 97558 – [chromium] platform/chromium/fast/forms/date/date-suggestion-picker-appearance-rtl.html is flaky on mac debug

• Component: Forms
• Status: RESOLVED WONTFIX

[Keishi Hattori]

Rebaseline test fast/forms/date/date-suggestion-picker-appearance.html

[Ojan Vafai]

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.

[Ojan Vafai]

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.

[Dirk Pranke]

that's a fun source of flakiness, alright.

[Keishi Hattori]

Created attachment 166569 [details]
Patch

[Ojan Vafai]

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?

[Kent Tamura]

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.

[Ryosuke Niwa]

I think we should first make sure that our conjuncture about the bug is correct.

[Ojan Vafai]

(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)?

[Ryosuke Niwa]

(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.

[Ojan Vafai]

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.

[Keishi Hattori]

(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.

[Stephen Chenney]

Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests.