http/tests/local/fileapi/file-last-modified-after-delete.html is flaky on mac-wk1 after <https://trac.webkit.org/changeset/200032> Most recent failure: <https://build.webkit.org/results/Apple%20Yosemite%20Release%20WK1%20(Tests)/r200041%20(14081)/results.html> Flakiness dashboard: <http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Flocal%2Ffileapi%2Ffile-last-modified-after-delete.html> --- /Volumes/Data/slave/yosemite-release-tests-wk1/build/layout-test-results/http/tests/local/fileapi/file-last-modified-after-delete-expected.txt +++ /Volumes/Data/slave/yosemite-release-tests-wk1/build/layout-test-results/http/tests/local/fileapi/file-last-modified-after-delete-actual.txt @@ -6,7 +6,7 @@ PASS event.dataTransfer contains a File object on drop. PASS lastModified is not null PASS lastModified is >= testStartTime.getTime() -PASS (new Date()).getTime() is >= lastModified +FAIL (new Date()).getTime() should be >= lastModified. Was 1461615786287 (of type number). PASS successfullyParsed is true TEST COMPLETE
I have a clean tree, will look now.
Attempt to fix in http://trac.webkit.org/changeset/200051
I think I see what's going on here. The File.lastModified accessor is returning a fractional number of milliseconds since the epoch. e.g., 1461624859783.417 Then the test end date is rounded to an integer number of milliseconds since epoch. e.g., 1461624859788 Those could very easily conflict the wrong way. e.g. 1461624859783.241 and 1461624859783.0 (1461624859783.49 rounded down) Gotta do the rounding on the File's return value. What's entirely unclear to me is how my change actually affected this. This should've been an existing problem.
(In reply to comment #3) > I think I see what's going on here. > > The File.lastModified accessor is returning a fractional number of > milliseconds since the epoch. > e.g., 1461624859783.417 > > Then the test end date is rounded to an integer number of milliseconds since > epoch. > e.g., 1461624859788 > > Those could very easily conflict the wrong way. > e.g. 1461624859783.241 and 1461624859783.0 (1461624859783.49 rounded down) > > Gotta do the rounding on the File's return value. > > What's entirely unclear to me is how my change actually affected this. This > should've been an existing problem. Never mind - it is entirely clear! lastModifiedDate used to be a Date object, which takes care of this. lastModified is a double, which does not. Fixing.
http://trac.webkit.org/changeset/200061