Bug 156994
| Summary: | http/tests/local/fileapi/file-last-modified-after-delete.html is flaky on mac-wk1 after r200032 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryan Haddad <ryanhaddad> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | beidson |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 154968 | ||
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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