Closed Bug 464962 Opened 16 years ago Closed 16 years ago

Zoom-Level reset to default when switching tabs while in Private Browsing Mode

Categories

(Firefox :: Private Browsing, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: luke.iliffe, Assigned: ehsan.akhgari)

References

Details

(Keywords: verified1.9.1)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre

When in the new private browsing mode setting the zoom level to anything other than default will be lost after switch to a second tab then back to the zoomed page.

Reproducible: Always

Steps to Reproduce:
1.Switch to Private Browsing Mode
2.Open tab#1
3.Increase the zoom level for Tab#1
4.Open tab #2
5.Switch back to Tab#1 -> zoom level will be set to default a few milliseconds later
Actual Results:  
Zoom level is reset

Expected Results:  
Site zoom level maintained whilst in the same private browsing session.
Gavin, are you familiar with page zoom code?  We disable saving anything in the content prefs module, but the page should remember its zoom setting once set manually across tab switches, isn't it?
Confirming on Windows.  Marcia, can you check Mac as well?
Assignee: nobody → ehsan.akhgari
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3.1?
Target Milestone: --- → Firefox 3.1
Version: unspecified → Trunk
We set the page zoom from prefs on every tab switch:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-textZoom.js#229

Seems like we should avoid doing that while PB is enabled. Or perhaps just have siteSpecific be false in PB mode.
Yes, this happens on mac as well.

(In reply to comment #2)
> Confirming on Windows.  Marcia, can you check Mac as well?
(In reply to comment #3)
> Or perhaps just have siteSpecific be false in PB mode.

That seems sensible to me. This blocks final release.
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P2
Attached patch Patch (v1) (obsolete) — Splinter Review
Patch with test.
Attachment #351241 - Flags: review?(gavin.sharp)
Status: NEW → ASSIGNED
Attached patch Patch (v1) (obsolete) — Splinter Review
I just realized that I had forgot to qrefresh the patch, so please ignore the previous patch.  :-)
Attachment #351241 - Attachment is obsolete: true
Attachment #351351 - Flags: review?(gavin.sharp)
Attachment #351241 - Flags: review?(gavin.sharp)
Whiteboard: [has patch][needs review gavin]
Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.
Component: General → Private Browsing
QA Contact: general → private.browsing
OS: Windows XP → All
Hardware: x86 → All
Gavin: ping?
Comment on attachment 351351 [details] [diff] [review]
Patch (v1)

>diff --git a/browser/base/content/browser-textZoom.js b/browser/base/content/browser-textZoom.js

>+    if (gPrivateBrowsingUI.privateBrowsingEnabled)
>+      this._onEnterPrivateBrowsing();
>+    else
>+      this._onLeavePrivateBrowsing();

I'd get rid of _onEnter and _onLeave and just assign to this._inPrivateBrowsing, with a similar change to have the pref set _siteSpecificPref, and then turn siteSpecific into a getter that just returns !_inPrivateBrowsing && _siteSpecificPref. I think the function call overhead of the getter is outweighed by the convenience of not having to check all of the siteSpecific setting codepaths to ensure they don't conflict.

Could also just always have it check the service directly and avoid the observer, since the getter for privateBrowsingEnabled is just a JS property get, but this method is called on every tab switch and page load, so perhaps it's not a bad idea to avoid the xpconnect overhead... Things like this certainly make a difference on Fennec, but for Firefox it probably matters less.

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>+  // initialize the private browsing UI
>+  gPrivateBrowsingUI.init();

>   // Initialize the full zoom setting.

>-  // initialize the private browsing UI
>-  gPrivateBrowsingUI.init();

Why is this change needed?
Attached patch Patch (v2)Splinter Review
(In reply to comment #11)
> I'd get rid of _onEnter and _onLeave and just assign to
> this._inPrivateBrowsing, with a similar change to have the pref set
> _siteSpecificPref, and then turn siteSpecific into a getter that just returns
> !_inPrivateBrowsing && _siteSpecificPref. I think the function call overhead of
> the getter is outweighed by the convenience of not having to check all of the
> siteSpecific setting codepaths to ensure they don't conflict.

Done.

> >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js
> 
> >+  // initialize the private browsing UI
> >+  gPrivateBrowsingUI.init();
> 
> >   // Initialize the full zoom setting.
> 
> >-  // initialize the private browsing UI
> >-  gPrivateBrowsingUI.init();
> 
> Why is this change needed?

Because FullZoom_init tries to use gPrivateBrowsingUI, so it should be inited before the full zoom object.
Attachment #351351 - Attachment is obsolete: true
Attachment #358150 - Flags: review?(gavin.sharp)
Attachment #351351 - Flags: review?(gavin.sharp)
Comment on attachment 358150 [details] [diff] [review]
Patch (v2)

Oh, I didn't notice the dependency. I don't think it's worth the inter-file dependency just to avoid a getService call, so I think you should omit that change and just get the privateBrowsingService directly rather than relying on gPrivateBrowsingUI initialization happening first.
Attachment #358150 - Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][needs review gavin] → [has patch]
Landed with the requested change on mozilla-central:
<http://hg.mozilla.org/mozilla-central/rev/e1962b8ae522>
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: Firefox 3.1 → Firefox 3.2a1
Verified on trunk and 1.9.1 branch with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090124 Minefield/3.2a1pre ID:20090124020327

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090123033224

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre ID:20090124020525

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) Ubiquity/0.1.5 ID:20090124033656
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: