526828 - browser.zoom.siteSpecific is not honored while in private browsing

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Frank Griswold [:griswolf] [:fgriswold]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091105 Namoroka/3.6b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091105 Namoroka/3.6b2pre

When following a link from a zoomed (+) page to the next page, the zoom is lost. Occurs only when in private browsing mode

Reproducible: Always

Steps to Reproduce:
1.enter private browsing
2. go to a site with a link to a next page
3. (zoom reset then) zoom +
4. follow the link, note the loss of zoom
Actual Results:  
zoom was reset downward, to, I think, reset value

Expected Results:  
zoom factor should be retained when browser.zoom.siteSpecific is true

Have not tested this on, e.g. wikipedia

Comment 1

[Jo Hermans]

dupe of bug 476514 ?

The problem is that in private mode, all writing to the content-prefs.sqlite database is sabotaged. You can still see it applied in the current page, but the value isn't saved, so it will not be found back on the next page.

Comment 2

[Frank Griswold [:griswolf] [:fgriswold]]

that seems wrong: Changes of that type should persist for the duration of the private session. Why not use in-memory sqlite that is set to not persist its content on exit (from private mode). You'd probably want to write through to persistent storage for some content types

Comment 3

[Jo Hermans]

I was just pointing out that the implementers only used the easy solution for private browsing - all write operations were sabotages. A better solution would indeed be to switch to a a different database. Note that an in-memory solution would indeed be best (you can't accidentally leave a trace on disk), but that might also require a lot of memory (duplicating places.sqlite in memory would not be a good idea).

Comment 4

[Jason Tackaberry]

I can confirm this bug, and it is also present in 4.0b1.

The opposite is true as well: with private browsing, siteSpecific=false is not honored either.  Namely, each page load, the browser resets the zoom level to 100%, even after the user has explicitly changed zoom levels.  IMO, Firefox should not touch the zoom level ever when siteSpecific is false.

This makes private browsing unusable with respect to zooming.

I'm the developer of the NoSquint extension, and I have to resort to hideous and fairly visible hacks to make this work at all (namely, queue a rezoom of the page after something like 100ms following a nsIWebProgressListener.STATE_STOP event).

Comment 5

[Jeff Cook]

I just voted for this bug, I find this annoying too. Note that Chromium also starts with a blank slate re: zoom levels in new incognito windows, but it maintains the setting for the duration of that window's life. Firefox should do the same thing and keep this info in memory somewhere instead of just ignoring it.

For people who rely on zoom, this is a really annoying issue. It is also a possible accessibility problem.

Comment 6

[Drew Willcoxon :adw]

This was fixed by bug 679784, which does pretty much what the comments here suggest: use a temporary, in-memory data store during PB mode.