RESOLVED FIXED 143697
fast/sub-pixel/input-caret-on-subpixel-bound.html is flaky 
https://bugs.webkit.org/show_bug.cgi?id=143697
Summary fast/sub-pixel/input-caret-on-subpixel-bound.html is flaky
Alexey Proskuryakov
Reported 2015-04-13 22:31:02 PDT
fast/sub-pixel/input-caret-on-subpixel-bound.html is flaky on debug WK2 bots. It's a reftest for editing, and caret is not drawn in actual result sometimes. There is a race between a caret blinking timer, and a timer in the test.
Attachments
proposed fix (1.41 KB, patch)
2015-04-13 22:34 PDT, Alexey Proskuryakov 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2015-04-13 22:34:17 PDT
Created attachment 250694 [details] proposed fix I have a vague memory of us doing something special to always have the caret draw when dumping pixel results, but I cannot find any sign of that in the code.
Alexey Proskuryakov
Comment 2 2015-04-13 22:44:35 PDT
There is a function in FrameSelection named setCaretBlinks which we could potentially call from Internals, but it's completely unused now, and may or may not work. Looks like it was accidentally added when upstreaming iOS code.
Alexey Proskuryakov
Comment 3 2015-04-14 09:48:24 PDT
We should probably delete setCaretBlinks and supporting code, and if we want to disable blinking during tests, we should do that by supporting and tweaking NSTextInsertionPointBlinkPeriod/NSTextInsertionPointBlinkPeriodOn/NSTextInsertionPointBlinkPeriodOff.
WebKit Commit Bot
Comment 4 2015-04-14 10:35:05 PDT
Comment on attachment 250694 [details] proposed fix Clearing flags on attachment: 250694 Committed r182801: <http://trac.webkit.org/changeset/182801>
WebKit Commit Bot
Comment 5 2015-04-14 10:35:09 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.