Bug 156994 – http/tests/local/fileapi/file-last-modified-after-delete.html is flaky on mac-wk1 after r200032

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Ryan Haddad]

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

[Brady Eidson]

I have a clean tree, will look now.

[Brady Eidson]

Attempt to fix in http://trac.webkit.org/changeset/200051

[Brady Eidson]

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.

[Brady Eidson]

(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.

[Brady Eidson]

http://trac.webkit.org/changeset/200061