Closed
Bug 486655
Opened 15 years ago
Closed 15 years ago
test_privatebrowsing_title.xul fails on Windows and Linux
Categories
(Firefox :: Private Browsing, defect)
Firefox
Private Browsing
Tracking
()
RESOLVED
FIXED
Firefox 3.6a1
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
()
Details
(Keywords: dev-doc-complete, fixed1.9.1, intermittent-failure)
Attachments
(1 file)
1.64 KB,
patch
|
Mardak
:
review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
This may have something to do with landing of bug 463256, but I can't reproduce it locally... Failure log: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1238751338.1238759730.4056.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1238751338.1238757093.30768.gz
Comment 1•15 years ago
|
||
Failed a second time on both Windows and Linux, so I backed out bug 463256. http://hg.mozilla.org/mozilla-central/rev/8a0ba5d85989
Blocks: 463256
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•15 years ago
|
||
This is very weird. We have three |is| checks: <http://hg.mozilla.org/mozilla-central/file/1886b176f000/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul#l104> <http://hg.mozilla.org/mozilla-central/file/1886b176f000/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul#l111> <http://hg.mozilla.org/mozilla-central/file/1886b176f000/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul#l118> And in the failure log we get four: *** 1358 INFO TEST-PASS | chrome://mochikit/content/chrome/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul | The downloads window title is correct outside of the private browsing mode *** 1359 INFO TEST-PASS | chrome://mochikit/content/chrome/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul | The downloads window title is correct inside the private browsing mode *** 1360 INFO TEST-PASS | chrome://mochikit/content/chrome/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul | The downloads window title is correct outside of the private browsing mode *** 1361 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/mozapps/downloads/tests/chrome/test_privatebrowsing_title.xul | The downloads window title is correct after leaving the private browsing mode - got "some title", expected "Downloads" The log lines 1, 2 and 4 are expected logs, and the third line should never happen. When I run the test on my own box repeatedly, I get this failure intermittently, and on runs where no error is reported, we actually get three checks, as expected. Runs which fail all have four checks like above. Still investigating...
Assignee | ||
Comment 3•15 years ago
|
||
It may be possible for the observer in this test to catch "download-manager-ui-done" twice because toggling the private browsing mode might trigger the notification as well, which would cause the test code to be run twice. By removing the observer as soon as the first "download-manager-ui-done" notification is observed, we eliminate this possibility.
Attachment #370862 -
Flags: review?(sdwilsh)
Assignee | ||
Updated•15 years ago
|
Attachment #370862 -
Flags: review?(sdwilsh) → review?(edilee)
Comment 4•15 years ago
|
||
Comment on attachment 370862 [details] [diff] [review] Remove the observer ASAP r+Mardak Test only change. And we don't actually use download-manager-ui-done anywhere other than in tests. But I wonder if there's a good place to document that the notification can be sent multiple times.. (or I suppose that's implicit to the notification..)
Attachment #370862 -
Flags: review?(edilee) → review+
Assignee | ||
Comment 5•15 years ago
|
||
(In reply to comment #4) > (From update of attachment 370862 [details] [diff] [review]) > r+Mardak > > Test only change. And we don't actually use download-manager-ui-done anywhere > other than in tests. But I wonder if there's a good place to document that the > notification can be sent multiple times.. (or I suppose that's implicit to the > notification..) I guess this is worth documenting anyway; adding the dev-doc-needed keyword (not sure if that notification is already documented on MDC)
Keywords: dev-doc-needed
Comment 6•15 years ago
|
||
Yeah, I think it just needs to note that the notification is sent any time the list finishes building, which can be triggered by opening the download manager window, removing multiple items, or entering private browsing.
Assignee | ||
Comment 7•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/3a2bc1fc8feb
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Comment 8•15 years ago
|
||
Comment on attachment 370862 [details] [diff] [review] Remove the observer ASAP a191=beltzner
Attachment #370862 -
Flags: approval1.9.1+
Assignee | ||
Comment 9•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/490e8e218fe6
Keywords: fixed1.9.1
Updated•15 years ago
|
Keywords: dev-doc-needed → dev-doc-complete
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•