Open Bug 576220 Opened 10 years ago Updated 4 years ago
_history _sidebar .js | 8 == 9 - unit test failure
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/mozilla-central-fedora64-opt-u-xpcshell/build/xpcshell/tests/test_places/unit/test_history_sidebar.js | test failed (with xpcshell return code: 0), see following log: >>>>>>> TEST-INFO | (xpcshell/head.js) | test 1 pending TEST-PASS | /home/cltbld/talos-slave/mozilla-central-fedora64-opt-u-xpcshell/build/xpcshell/tests/test_places/unit/head_bookmarks.js -> file:///home/cltbld/talos-slave/mozilla-central-fedora64-opt-u-xpcshell/build/xpcshell/tests/test_places/head_common.js | [check_no_bookmarks : 283] 0 == 0
Maybe related to 552386 (which is fixed) I did verify that the fix is still in m-c after the e10s merge.
hum, really strange, has started with a changeset at Wed Jun 30 21:48:27 2010 PDT the older than 6 months container is missing. Some calculation issue with February duration?
Component: History: Global → Places
Product: Core → Toolkit
QA Contact: history.global → places
I don't think this is a DST problem, so should be unrelated to other fixes.
the problem has stopped around Wed Jun 30 23:28:42 2010 PDT
could have been fixed (on places branch so far) by bug 603002, but it's hard to verify
Depends on: 603002
marking as fixed since the underlying bug is fixed, reopen if you still notice it (in case there were more than 1 problems)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [orange][time-bomb] → [orange][time-bomb][fixed by bug 603002]
Target Milestone: --- → mozilla2.0b9
This just started happening again: as soon as we crossed midnight from June 30 / July 1 (PST), every xpcshell test on m-c is failing with this error. Removing the "[fixed by bug 603002]' annotation as it does not appear to be truly fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [orange][time-bomb][fixed by bug 603002] → [orange][time-bomb]
This patch eliminates the faulty test in two ways, (1) removing the DST handling code, and (2) aiming for a date in the middle of the month instead of near the end. Still not sure why it only affects July 1 though. Might be a February issue?
Comment on attachment 543396 [details] [diff] [review] patch You're right Marco, this is a dumb idea. And in any case I've found a real bug.
Okay, here's the real bug, since I wasted my time figuring it out: July 1 before 0100, minus an hour for DST (Northern Hemisphere only), is June 30 January 31 to June 30 is 150 days http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsNavHistory.cpp#176 When _daysFromOldestVisit is 150, this macro returns 5 instead of 6 that we're expecting. Thus January 31, in extremely limited circumstances, is a part of February.
Whiteboard: [orange][time-bomb] → [time-bomb]
You need to log in before you can comment on or make changes to this bug.