Last Comment Bug 663886 - Manual zoom reduction (85%) does not hold and returns to 100% with routine navigation within a website.
: Manual zoom reduction (85%) does not hold and returns to 100% with routine na...
Product: SeaMonkey
Classification: Client Software
Component: General (show other bugs)
: SeaMonkey 2.1 Branch
: All All
-- normal with 1 vote (vote)
: seamonkey2.13
Assigned To: hhaamu
Depends on:
  Show dependency treegraph
Reported: 2011-06-13 10:40 PDT by John
Modified: 2012-07-11 11:05 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Screenshot. (16.70 KB, image/png)
2011-07-05 17:43 PDT, therube
no flags Details
Screenshot. (17.46 KB, image/png)
2011-07-05 17:44 PDT, therube
no flags Details
untested (3.43 KB, patch)
2012-07-10 08:57 PDT, hhaamu
no flags Details | Diff | Splinter Review
untested v2 (3.43 KB, patch)
2012-07-10 09:07 PDT, hhaamu
neil: review+
Details | Diff | Splinter Review

Description User image John 2011-06-13 10:40:51 PDT
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1

Manual screen size reduction (85%) does not hold and returns to 100% with routine navigation within a website (fuBar, ex.)

Reproducible: Always
Comment 1 User image Philip Chee 2011-06-13 11:30:28 PDT
Have you discussed this in our support forums yet?
Go to about:config
and filter for
Is it set to True?
Comment 2 User image John 2011-06-13 15:53:14 PDT
No I have not discussed this in the Forums yet.  Also, I experienced this identical problem at the time of a previous upgrade introduction.  At that time I simply used another browser and apparently it was resolved in the meantime.  I just checked the browser.zoom.siteSpecific setting as recommended and it is set to 'True'.  Problem is still present and makes the operation of the new Seamonkey configuration unusable, however the previous version works fine.  I would rather use the new, however.
Comment 3 User image John 2011-06-13 16:11:37 PDT
Further testing now indicates the problem has been eliminated (at present) and reduction in screen size is holding in varying operations within the site.  Thank you.
Comment 4 User image John 2011-06-15 10:10:46 PDT
Problem still exists when reduction is set at a non-preset position like 85% in this case.  75 and 90% preset choices hold OK.
Comment 5 User image Philip Chee 2011-06-16 03:01:42 PDT
Re-opening based on comment 4
Comment 6 User image therube 2011-07-05 17:38:24 PDT
Looks like /toolkit.zoomManager.zoomValues/ defaults to:


FF shows no zoom "value", only offers Zoom In or Zoom Out.
FF looks to be able to Zoom in/out to all of those values.
FF has no "Other (xxx%)" user-set zoom level (as SeaMonkey does).

SeaMonkey looks to use only a subset (or different, in the case of .75, or missing, 1.1 & others) of that data (though the default value is the same):


Only for that particular set (though not necessarily "default") of values, is the value of /browser.content.full-zoom/ updated & retained.

Any other user selected value reverts back to the last set value (from browser.content.full-zoom) on that list.
Comment 7 User image therube 2011-07-05 17:43:46 PDT
Created attachment 544109 [details]

Data Manager showing FF values retained.

(Actual shot only /shows/ that way as it updates, but not refreshes.  In actuality there is only one value there.)
Comment 8 User image therube 2011-07-05 17:44:26 PDT
Created attachment 544110 [details]

Data Manager showing SeaMonkey values retained.
Comment 9 User image Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention) 2011-07-05 21:10:32 PDT
Related with bug 621823?
Comment 10 User image Philip Chee 2012-07-08 12:02:57 PDT
John, now that bug 621823 is fixed, do you still encounter the issue?
Comment 11 User image hhaamu 2012-07-08 12:51:54 PDT
I can test this (assuming bug 621823 has landed on 2.9 -- I think it has)

browser.zoom.siteSpecific = true
browser.zoom.full = false

1. Setting zoom to 115% (a non-default value) zooms to that normally
2. The moment I load a new page (click a link) or change tab or navigate back/forth within the same domain, it resets the zoom to 100%

So yes, still reproducible.
Comment 12 User image hhaamu 2012-07-10 08:04:53 PDT
If I zoom with the mouse wheel (with its 10% increments), the zoom is remembered. Only the View -> Text Zoom -> Other option is having trouble.
Comment 13 User image hhaamu 2012-07-10 08:13:33 PDT
And if I set Other to 115%, and mouse wheel up to 125% and then back down, it remembers it properly. This definitely sounds like something is missing a hook.
Comment 14 User image hhaamu 2012-07-10 08:57:42 PDT
Created attachment 640618 [details] [diff] [review]

setZoomOther() was missing a call to _applySettingToPref()

I moved it to FullZoom.setZoomOther() where the other four functions were.

Please note that this patch is completely untested. Would appreciate if someone could test it.
Comment 15 User image hhaamu 2012-07-10 09:07:17 PDT
Created attachment 640623 [details] [diff] [review]
untested v2
Comment 16 User image Philip Chee 2012-07-10 12:59:14 PDT
Comment on attachment 640623 [details] [diff] [review]
untested v2

Setting appropriate review flags, otherwise this patch will never make it into the codebase.
Comment 17 User image Philip Chee 2012-07-10 13:00:10 PDT
p.s. hhaamu thanks for the patch!
Comment 18 User image hhaamu 2012-07-11 09:29:58 PDT
(I do hope someone has tested this patch before it is checked in. I'm unable to test it currently.)
Comment 19 User image Philip Chee 2012-07-11 11:05:19 PDT
Pushed to comm-central:

Note You need to log in before you can comment on or make changes to this bug.