Manual zoom reduction (85%) does not hold and returns to 100% with routine navigation within a website.

RESOLVED FIXED in seamonkey2.13

Status

SeaMonkey
General
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: John, Assigned: hhaamu)

Tracking

SeaMonkey 2.1 Branch
seamonkey2.13

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

16.70 KB, image/png
Details
17.46 KB, image/png
Details
3.43 KB, patch
neil@parkwaycc.co.uk
: review+
Details | Diff | Splinter Review
(Reporter)

Description

6 years ago
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

6 years ago
Have you discussed this in our support forums yet?
Go to about:config
and filter for
browser.zoom.siteSpecific
Is it set to True?
Component: Page Info → General
QA Contact: page-info → general
Version: unspecified → SeaMonkey 2.1 Branch
(Reporter)

Comment 2

6 years ago
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.
(Reporter)

Comment 3

6 years ago
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.

Updated

6 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

6 years ago
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

6 years ago
Re-opening based on comment 4
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---

Comment 6

6 years ago
Looks like /toolkit.zoomManager.zoomValues/ defaults to:

.3,.5,.67,.8,.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3

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):

0.5,0.75,0.9,1,1.2,1.5,2.

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

6 years ago
Created attachment 544109 [details]
Screenshot.

 
 
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

6 years ago
Created attachment 544110 [details]
Screenshot.

 
 
Data Manager showing SeaMonkey values retained.
Related with bug 621823?

Comment 10

5 years ago
John, now that bug 621823 is fixed, do you still encounter the issue?
(Assignee)

Comment 11

5 years ago
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.
(Assignee)

Comment 12

5 years ago
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.
(Assignee)

Comment 13

5 years ago
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.
(Assignee)

Comment 14

5 years ago
Created attachment 640618 [details] [diff] [review]
untested

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.
(Assignee)

Comment 15

5 years ago
Created attachment 640623 [details] [diff] [review]
untested v2
Attachment #640618 - Attachment is obsolete: true

Comment 16

5 years ago
Comment on attachment 640623 [details] [diff] [review]
untested v2

Setting appropriate review flags, otherwise this patch will never make it into the codebase.
Attachment #640623 - Flags: review?(neil)

Comment 17

5 years ago
p.s. hhaamu thanks for the patch!
Status: REOPENED → NEW

Updated

5 years ago
Attachment #640623 - Flags: review?(neil) → review+

Updated

5 years ago
Assignee: nobody → hhaamu
Status: NEW → ASSIGNED
Keywords: checkin-needed
(Assignee)

Comment 18

5 years ago
(I do hope someone has tested this patch before it is checked in. I'm unable to test it currently.)

Comment 19

5 years ago
Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/d63b11ddcd55
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago5 years ago
Keywords: checkin-needed
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Summary: Manual screen size reduction (85%) stability → Manual zoom reduction (85%) does not hold and returns to 100% with routine navigation within a website.
Target Milestone: --- → seamonkey2.13
You need to log in before you can comment on or make changes to this bug.