media/track/track-in-band-style.html is flaky: Diff: --- /Volumes/Data/slave/mojave-release-tests-wk2/build/layout-test-results/media/track/track-in-band-style-expected.txt +++ /Volumes/Data/slave/mojave-release-tests-wk2/build/layout-test-results/media/track/track-in-band-style-actual.txt @@ -14,6 +14,6 @@ ** Test current cue colors EXPECTED (getComputedStyle(cueDisplayElement).color == 'rgb(255, 255, 255)') OK -EXPECTED (getComputedStyle(cueNode).backgroundColor == 'rgb(0, 0, 0)') OK +EXPECTED (getComputedStyle(cueNode).backgroundColor == 'rgb(0, 0, 0)'), OBSERVED 'rgba(0, 0, 0, 0)' FAIL END OF TEST It started happening after https://trac.webkit.org/changeset/243094 although I bet this change merely impacted the timing.
I can reproduce like so: run-webkit-tests -gf --repeat-each=100 media/track/track-in-band-style.html
If I add logging to InbandTextTrackPrivateAVF::processCueAttributes() and run the test, I see that cueData.setForegroundColor(color) gets called with 'rgb(255, 255, 255)'. However, I never see any call to cueData.setBackgroundColor(color), no matter if the test passes or fail. Therefore, I am unsure where 'rgb(0, 0, 0)' and 'rgba(0, 0, 0, 0)' come from. Maybe some default values?
It looks like Color().cssText() returns "rgba(0, 0, 0, 0)" so it would make sense for the background color to be rgba(0, 0, 0, 0) if it does not get set.
(In reply to Chris Dumez from comment #3) > It looks like Color().cssText() returns "rgba(0, 0, 0, 0)" so it would make > sense for the background color to be rgba(0, 0, 0, 0) if it does not get set. Although I do not see the AV code setting the cue's backgroundColor, it does set the highlightColor. The highlightColor ends up being set as css background-color for the element.
Created attachment 365177 [details] Patch
Comment on attachment 365177 [details] Patch thanks cdumez!
Comment on attachment 365177 [details] Patch Clearing flags on attachment: 365177 Committed r243164: <https://trac.webkit.org/changeset/243164>
All reviewed patches have been landed. Closing bug.
<rdar://problem/49031582>
We have a flaky timeout expectation for this test. I don't imagine this is likely to fix it, is it? LayoutTests/platform/mac/TestExpectations:1370:webkit.org/b/171465 media/track/track-in-band-style.html [ Pass Timeout ]
(In reply to Alexey Proskuryakov from comment #10) > We have a flaky timeout expectation for this test. I don't imagine this is > likely to fix it, is it? > > LayoutTests/platform/mac/TestExpectations:1370:webkit.org/b/171465 > media/track/track-in-band-style.html [ Pass Timeout ] No sorry, I don't think my change would help address a timeout.