50471 2010-12-03 12:21:32 -0800 media/controls-without-preload.html failing on Windows 2023-10-14 03:28:44 -0700 1 1 1 Unclassified WebKit Media 528+ (Nightly build) All Windows 7 RESOLVED CONFIGURATION CHANGED InRadar, LayoutTestFailure, PlatformOnly P2 Normal --- 1 jberlin webkit-unassigned ahmad.saleem792 aroben eric.carlson jberlin mrobinson pnormand oldest_to_newest 316958 0 jberlin 2010-12-03 12:21:32 -0800 It has been failing on both Windows 7 and XP: http://build.webkit.org/results/Windows%207%20Release%20(Tests)/r73278%20(7105)/media/controls-without-preload-actual.txt The failures have been happening since the test results were committed: http://trac.webkit.org/changeset/73278 Which were separate from the tests being added: http://trac.webkit.org/changeset/73257 316978 1 jberlin 2010-12-03 12:53:40 -0800 Committed the windows-specific results in r73288 http://trac.webkit.org/changeset/73288 317176 2 pnormand 2010-12-03 16:48:15 -0800 Can r73278 please be reverted? The test expectations are platform-specific. 358094 3 jberlin 2011-02-25 11:43:03 -0800 Still failing on XP. I think the XP failures started with r78690: http://build.webkit.org/old-results/Windows%20XP%20Debug%20(Tests)/r78690%20(25314)/results.html http://build.webkit.org/old-results/Windows%20XP%20Debug%20(Tests)/r78689%20(25313)/results.html I will commit the expected failing results for XP soon. 358107 4 eric.carlson 2011-02-25 12:08:02 -0800 (In reply to comment #3) > Still failing on XP. I think the XP failures started with r78690: > > http://build.webkit.org/old-results/Windows%20XP%20Debug%20(Tests)/r78690%20(25314)/results.html > http://build.webkit.org/old-results/Windows%20XP%20Debug%20(Tests)/r78689%20(25313)/results.html > > I will commit the expected failing results for XP soon. I think it would be better to add the test to the skipped list and file a bug instead of committing failing result.s 358120 5 jberlin 2011-02-25 12:38:55 -0800 Hrm, well I comitted the failing results in http://trac.webkit.org/changeset/79716 before your comment. They don't seem to be flakey, just consistently failing with those results. Would it really be more useful to remove these expected results and just add it to the skip lists? 358122 6 eric.carlson 2011-02-25 12:42:57 -0800 (In reply to comment #5) > Hrm, well I comitted the failing results in http://trac.webkit.org/changeset/79716 before your comment. > > They don't seem to be flakey, just consistently failing with those results. Would it really be more useful to remove these expected results and just add it to the skip lists? Yes, I do think it is better to have a failing file in the skipped list rather than using incorrect results. 358124 7 aroben 2011-02-25 12:47:48 -0800 (In reply to comment #4) > (In reply to comment #3) > > Still failing on XP. I think the XP failures started with r78690: > > > > http://build.webkit.org/old-results/Windows%20XP%20Debug%20(Tests)/r78690%20(25314)/results.html > > http://build.webkit.org/old-results/Windows%20XP%20Debug%20(Tests)/r78689%20(25313)/results.html > > > > I will commit the expected failing results for XP soon. > > I think it would be better to add the test to the skipped list and file a bug instead of committing failing result.s A bug has been filed: this one. Committing expected failure results has been our policy for a while now. We do this when a test is failing in a consistent way and is not crashing or timing out. The advantage of committing expected failure results is that we will notice if someone causes a change in the test's behavior (including fixing it!). A number of people say that it's better to have the test in the Skipped file because then there's a record that it's failing. However, this bug records that the test is failing, and people don't seem to look through the Skipped file to see what tests are failing much in practice. 358125 8 jberlin 2011-02-25 12:47:55 -0800 <rdar://problem/9055504> 1985075 9 ahmad.saleem792 2023-10-14 03:28:44 -0700 This expectation does not exist for win-cairo and only have for GTK and tracked with separate bug. It might be for 'AppleWin' port, which is gone. Marking this as 'RESOLVED CONFIGURATION CHANGED' since nothing to do here.