Closed
Bug 473860
Opened 16 years ago
Closed 16 years ago
Closing window after leaving Private browsing mode still shows "Stop Private Browsing" in Tools menu
Categories
(Firefox :: Private Browsing, defect, P2)
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
People
(Reporter: whimboo, Assigned: mconnor)
References
Details
(Keywords: verified1.9.1)
Attachments
(4 obsolete files)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090115 Shiretoko/3.1b3pre Ubiquity/0.1.4 ID:20090115020658
With the following steps we have an inconsistent behavior on OS X. Even the user is not in PB mode the tools menu item shows "Stop Private Browsing".
Steps:
1. Enter Private Browsing mode
2. Leave Private Browsing mode
3. Open the tools menu => "Start Private Browsing" is visible
4. Close Window
3. Open the tools menu => "Stop Private Browsing" is visible
No idea if this is really related to bug 463582. It's your decision Ehsan.
Flags: wanted-firefox3.1?
Flags: in-litmus?
Comment 1•16 years ago
|
||
Test case https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=7471 has been created for regression testing this bug.
Flags: in-litmus? → in-litmus+
Reporter | ||
Comment 2•16 years ago
|
||
I've disabled the test until this bug will be fixed.
Comment 3•16 years ago
|
||
Henrik, can you please try this patch and see if it fixes the problem? If you don't want to build, just go to firefox-dir/chrome, extract browser.jar and apply the patch to browser.js manually and re-zip it.
Thanks!
Comment 4•16 years ago
|
||
Sorry the previous patch contained some unwanted changes. This one is the right patch.
Attachment #358155 -
Attachment is obsolete: true
Reporter | ||
Comment 5•16 years ago
|
||
I've created a tryserver build with the latest patch which is available here:
https://build.mozilla.org/tryserver-builds/2009-01-22_01:55-hskupin@mozilla.com-bug473860/
For me the "Stop Private Browsing" label is still shown. There is no change with this patch. Anyone else running OS X can check it too? Thanks.
Updated•16 years ago
|
Whiteboard: [PB-P3]
Assignee | ||
Comment 6•16 years ago
|
||
That change is in init()... how would that work? onExitPrivateBrowsing should just work, but maybe we throw at http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#6942 in the non-browser window case?
Assignee | ||
Comment 7•16 years ago
|
||
Assignee: ehsan.akhgari → mconnor
Attachment #358157 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #364219 -
Flags: review?(gavin.sharp)
Updated•16 years ago
|
Attachment #364219 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•16 years ago
|
Attachment #364219 -
Flags: approval1.9.1?
Assignee | ||
Updated•16 years ago
|
Priority: -- → P2
Target Milestone: --- → Firefox 3.1b3
Comment 8•16 years ago
|
||
Comment on attachment 364219 [details] [diff] [review]
only reset gFindbar if it's not null
a191=beltzner
Attachment #364219 -
Flags: approval1.9.1? → approval1.9.1+
Assignee | ||
Updated•16 years ago
|
Flags: wanted-firefox3.1? → wanted-firefox3.1+
Comment 9•16 years ago
|
||
Bug 464736 added some similar code which should also be patched here.
Attachment #364219 -
Attachment is obsolete: true
Attachment #364509 -
Flags: review?(gavin.sharp)
Updated•16 years ago
|
Whiteboard: [PB-P3]
Assignee | ||
Updated•16 years ago
|
Attachment #364509 -
Flags: review?(gavin.sharp) → review-
Assignee | ||
Comment 10•16 years ago
|
||
Comment on attachment 364509 [details] [diff] [review]
do the same for the import menu item as well
the null checks on menuitems aren't needed, as the menuitems are should always be available.
Updated•16 years ago
|
Attachment #364509 -
Attachment is obsolete: true
Comment 11•16 years ago
|
||
Comment on attachment 364509 [details] [diff] [review]
do the same for the import menu item as well
Ah, right. I got too excited. ;-)
Do you want me to land the previous patch for you?
Comment 13•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews][ready to land]
Comment 14•16 years ago
|
||
Keywords: fixed1.9.1
Reporter | ||
Comment 15•16 years ago
|
||
Verified on trunk and 1.9.1 branch:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre ID:20090228023218
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090301 Shiretoko/3.1b3pre ID:20090301020400
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Target Milestone: Firefox 3.1b3 → Firefox 3.2a1
Comment 16•16 years ago
|
||
I renabled the litmus test case now that is has been fixed and verified.
Comment 17•13 years ago
|
||
jui
You need to log in
before you can comment on or make changes to this bug.
Description
•