137525 2014-10-08 10:10:16 -0700 REGRESSION (r174402): media/track/track-forced-subtitles-in-band.html fails 2014-10-20 22:54:31 -0700 1 1 1 Unclassified WebKit Media 528+ (Nightly build) Mac All RESOLVED FIXED P2 Normal --- 137472 137505 1 aestes jer.noble ap darin jer.noble oldest_to_newest 1040324 0 aestes 2014-10-08 10:10:16 -0700 After r174403, media/track/track-forced-subtitles-in-band.html has started failing on the Mac wk1 and wk2 test bots like so: --- /Volumes/Data/slave/mavericks-release-tests-wk2/build/layout-test-results/media/track/track-forced-subtitles-in-band-expected.txt +++ /Volumes/Data/slave/mavericks-release-tests-wk2/build/layout-test-results/media/track/track-forced-subtitles-in-band-actual.txt @@ -10,7 +10,7 @@ ** Forced tracks should be in .textTracks, but not in the menu EXPECTED (video.textTracks.length == '9') OK -EXPECTED (trackMenuItems.length == '6') OK +EXPECTED (trackMenuItems.length == '6'), OBSERVED '3' FAIL ** Only the 'fr' forced track should be showing EXPECTED (video.textTracks[0].language == 'en') OK See https://build.webkit.org/results/Apple%20Mavericks%20Release%20WK2%20(Tests)/r174451%20(8513)/results.html for more details. 1040326 1 aestes 2014-10-08 10:16:46 -0700 Updated TestExpectations in r174458: <http://trac.webkit.org/changeset/174458> 1040331 2 cdumez 2014-10-08 10:20:48 -0700 Ok, I'll take a look thanks 1040333 3 aestes 2014-10-08 10:21:34 -0700 r174402 is the culprit, not r174403. Off-by-one error on my part :) 1043080 4 ap 2014-10-20 20:11:24 -0700 This text has stopped failing on the next day, and is "only" flaky once again. Jer, do you know what fixed this? Could it be <http://trac.webkit.org/changeset/174460>? 1043087 5 jer.noble 2014-10-20 20:29:11 -0700 (In reply to comment #4) > This text has stopped failing on the next day, and is "only" flaky once > again. > > Jer, do you know what fixed this? Could it be > <http://trac.webkit.org/changeset/174460>? No, it was probably <http://trac.webkit.org/changeset/174472>. 1043107 6 ap 2014-10-20 22:54:31 -0700 Indeed - there was a large gap in coverage, so I didn't see that at first. Historical data agrees with r174472 being the fix. So, the fix for the "test is flaky" bug addressed it failing every time, but did not address the flakiness.