156994 2016-04-25 13:56:19 -0700 http/tests/local/fileapi/file-last-modified-after-delete.html is flaky on mac-wk1 after r200032 2016-04-25 17:12:07 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED P2 Normal --- 154968 1 ryanhaddad webkit-unassigned beidson oldest_to_newest 1187047 0 ryanhaddad 2016-04-25 13:56:19 -0700 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 1187057 1 beidson 2016-04-25 14:12:29 -0700 I have a clean tree, will look now. 1187066 2 beidson 2016-04-25 14:38:28 -0700 Attempt to fix in http://trac.webkit.org/changeset/200051 1187096 3 beidson 2016-04-25 15:57:52 -0700 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. 1187098 4 beidson 2016-04-25 16:00:20 -0700 (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. 1187132 5 beidson 2016-04-25 17:12:07 -0700 http://trac.webkit.org/changeset/200061