Summary: | [Win] Some JavaScript date tests are failing in non-California Timezones | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | peavo | ||||
Component: | Web Template Framework | Assignee: | Brent Fulgham <bfulgham> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | benjamin, bfulgham, cmarcelo, commit-queue, dbates, eflews.bot, ggaren, gyuyoung.kim, msaboff, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Unspecified | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=250553 | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 124450 | ||||||
Attachments: |
|
Description
peavo
2013-11-27 12:17:13 PST
Created attachment 217963 [details]
Patch
These are the results with the patch included: Results for Mozilla tests: 0 regressions found. 0 tests fixed. OK. Comment on attachment 217963 [details] Patch Attachment 217963 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/38598062 The efl-wk2 build seems to fail with an internal compiler error in a different file, so I don't think that is related to this patch. Do these same failures happen under Apple's Windows port? It looks like there are 11 jscore errors, but I can't see what those errors arson the buildbots. Still, they can' t be the same just based on counts. Should we only use this code path for the WinCairo port? (In reply to comment #6) > Do these same failures happen under Apple's Windows port? It looks like there are 11 jscore errors, but I can't see what those errors arson the buildbots. Still, they can' t be the same just based on counts. > > Should we only use this code path for the WinCairo port? Thanks for looking into this :) Yes, I get the exact same errors when running WinApple. The strange thing is that, when I change the timezone to e.g. California-time (UTC - 8.00, I think), there are no errors, both with, and without the patch. It seems the results depends on which timezone you are in, which might explain why we are seeing different results. With the patch, I get no errors in both timezones. To be on the safe side, I can make this patch WinCairo-only. Your call :) Comment on attachment 217963 [details]
Patch
R=me
Comment on attachment 217963 [details] Patch Clearing flags on attachment: 217963 Committed r159892: <http://trac.webkit.org/changeset/159892> All reviewed patches have been landed. Closing bug. (In reply to comment #7) > (In reply to comment #6) > > Do these same failures happen under Apple's Windows port? It looks like there are 11 jscore errors, but I can't see what those errors arson the buildbots. Still, they can' t be the same just based on counts. > > > Thanks for looking into this :) > > Yes, I get the exact same errors when running WinApple. > > The strange thing is that, when I change the timezone to e.g. California-time (UTC - 8.00, I think), there are no errors, both with, and without the patch. > It seems the results depends on which timezone you are in, which might explain why we are seeing different results. > > With the patch, I get no errors in both timezones. > Very interesting. I wonder if this indicates a general weakness in our test coverage. All of our test bots live in California, and use that time zone. Thanks for catching this! (In reply to comment #9) > (From update of attachment 217963 [details]) > Clearing flags on attachment: 217963 > > Committed r159892: <http://trac.webkit.org/changeset/159892> Using the data on the Flakiness Dashboard (*) as a starting point (**) and comparing the Windows {Debug, Release} expected results diffs, this commit regressed test LayoutTests/js/dom/date-big-constructor.html (*) <http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=js%2Fdom%2Fdate-big-constructor.html> (**) The Flakiness Dashboard only has data that shows the test passed in r159891 and failed since r159894. Looking at the commits in [r159891, r159894], <http://trac.webkit.org/changeset/159892> seemed relevant given that it's the only patch that touched code related to date logic. Moreover, the description of this bug is with regards to JavaScript date tests. Interesting! So we fixed ecma problems, but somehow broke a layout test? What is the layout test failure? Could it be that we had bad expectations checked in? (In reply to comment #12) > (In reply to comment #9) > > (From update of attachment 217963 [details] [details]) > > Clearing flags on attachment: 217963 > > > > Committed r159892: <http://trac.webkit.org/changeset/159892> > > Using the data on the Flakiness Dashboard (*) as a starting point (**) and comparing the Windows {Debug, Release} expected results diffs, this commit regressed test LayoutTests/js/dom/date-big-constructor.html > > [...] Filed bug #127492 for the regression. (In reply to comment #14) > Interesting! So we fixed ecma problems, but somehow broke a layout test? > Yes, according to the Flakiness Dashboard. > What is the layout test failure? Could it be that we had bad expectations checked in? Windows disagrees with the cross-platform expected results for the test. Windows Debug bot diff: <http://build.webkit.org/results/Apple%20Win%207%20Debug%20(Tests)/r162609%20(57442)/js/dom/date-big-constructor-pretty-diff.html> Window Release Bot diff (identical to the Windows Debug bot diff): <http://build.webkit.org/results/Apple%20Win%207%20Release%20(Tests)/r162610%20(41968)/js/dom/date-big-constructor-pretty-diff.html> |