test_privatebrowsing_title.xul fails on Windows and Linux

RESOLVED FIXED in Firefox 3.6a1

Status

()

Firefox
Private Browsing
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: Away for a while, Assigned: Away for a while)

Tracking

({dev-doc-complete, fixed1.9.1, intermittent-failure})

Trunk
Firefox 3.6a1
dev-doc-complete, fixed1.9.1, intermittent-failure
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
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
(Assignee)

Updated

9 years ago
Blocks: 464800
Whiteboard: [orange]
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

9 years ago
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
(Assignee)

Comment 2

9 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

9 years ago
Created attachment 370862 [details] [diff] [review]
Remove the observer ASAP

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

9 years ago
Attachment #370862 - Flags: review?(sdwilsh) → review?(edilee)

Comment 4

9 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

9 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

9 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

9 years ago
http://hg.mozilla.org/mozilla-central/rev/3a2bc1fc8feb
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Comment on attachment 370862 [details] [diff] [review]
Remove the observer ASAP

a191=beltzner
Attachment #370862 - Flags: approval1.9.1+
(Assignee)

Comment 9

9 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/490e8e218fe6
Keywords: fixed1.9.1
Keywords: dev-doc-needed → dev-doc-complete
(Assignee)

Updated

8 years ago
Blocks: 438871
Keywords: intermittent-failure
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.