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)

3.5 Branch
All
macOS
defect

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?
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+
I've disabled the test until this bug will be fixed.
Attached patch Patch (v1) (obsolete) (deleted) — Splinter Review
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!
Attached patch Patch (v1) (obsolete) (deleted) — Splinter Review
Sorry the previous patch contained some unwanted changes. This one is the right patch.
Attachment #358155 - Attachment is obsolete: true
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.
Whiteboard: [PB-P3]
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?
Attached patch only reset gFindbar if it's not null (obsolete) (deleted) — Splinter Review
Assignee: ehsan.akhgari → mconnor
Attachment #358157 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #364219 - Flags: review?(gavin.sharp)
Attachment #364219 - Flags: review?(gavin.sharp) → review+
Attachment #364219 - Flags: approval1.9.1?
Priority: -- → P2
Target Milestone: --- → Firefox 3.1b3
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+
Flags: wanted-firefox3.1? → wanted-firefox3.1+
Attached patch do the same for the import menu item as well (obsolete) (deleted) — Splinter Review
Bug 464736 added some similar code which should also be patched here.
Attachment #364219 - Attachment is obsolete: true
Attachment #364509 - Flags: review?(gavin.sharp)
Whiteboard: [PB-P3]
Attachment #364509 - Flags: review?(gavin.sharp) → review-
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.
Attachment #364509 - Attachment is obsolete: true
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?
Feel free.
Whiteboard: [has patch][has reviews][ready to land]
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews][ready to land]
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
Target Milestone: Firefox 3.1b3 → Firefox 3.2a1
Depends on: 480854
No longer depends on: 480854
I renabled the litmus test case now that is has been fixed and verified.
jui
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: