API test VideoControlsManager.VideoControlsManagerFullSizeVideoInWideMainFrame is a flaky failure
Value of: hasVideoForControlsManager
HAs something changed, or have we simply been not noticing this for so long?
(In reply to Alexey Proskuryakov from comment #1)
> HAs something changed, or have we simply been not noticing this for so long?
This seems to be a recent regression, perhaps sharing the same root cause as https://bugs.webkit.org/show_bug.cgi?id=175143
I am trying to reproduce both failures locally and identify a regression point.
This regressed with https://trac.webkit.org/changeset/220052/webkit
Skipped this flaky test in https://trac.webkit.org/changeset/220711/webkit
Jer, can you perhaps help me figure out why this is failing? I would like to fix it and re-enable the test.
Created attachment 319811 [details]
Passing all EWS now. Ready for someone to review.
Comment on attachment 319811 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=319811&action=review
> + video controls to appear. With changes to how loading occurrs, it can now
Nit - occurrs => occurs
> + changing the tests to wait one more run loop should get rid of the flakiness.
In the longer term, I think it makes more sense for some of these tests to expect media controls to show up eventually, instead of expecting them after a "playing" message sent after a 0-delay timer in the web process. As you noted, there isn't a guarantee of how many run loop cycles it would take for the web process to be in a state where it wants to show media controls, nor should there be, since touch bar presence for media elements isn't web/API exposed.
Committed r221589: <http://trac.webkit.org/changeset/221589>