851898 - Zoom will not go past 300%, use to be able to zoom to +/-800%

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[FourthDr]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2
Build ID: 20130310201055

Steps to reproduce:

Can't zoom beyond 300%. And can't increase zoom value in menu under "other (300%)..." ok button is grayed out if value larger than 300 is entered.


Actual results:

ctrl+ and ctrl- will not zoom more than 300% (three time). And can't increase zoom value in menu under "other (300%)..." ok button is grayed out if value larger than 300 is entered.


Expected results:

Should be able to zoom to + or - 800% as in earlier Seamonkey 2.0.14.

Comment 1

[Matthias Versen [:Matti]]

You want to change http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues in about:config

Comment 2

[[e-mail]]

(In reply to Matthias Versen from comment #1)
> You want to change http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues

Better still, the related zoom.maxPercent (and maybe minPrecent). (These work in the same versions of SeaMonkey as zoomValues, although mozillazine kb hasn't been updated.)

Comment 3

[Philip Chee]

Interestingly enough both Metro and Android use 20/400 as the min and max.
Toolkit is set to 30/300

Comment 4

[rsx11m]

(In reply to [e-mail] from comment #2)
> Better still, the related zoom.maxPercent (and maybe minPrecent).

Actually, IIRC you /have/ to increase that value as well in order to get additional zoom levels in toolkit.zoomManager.zoomValues beyond that recognized.

Note that while the Ctrl +/- keys follow the levels defined in zoomValues, using Ctrl along with the mouse wheel for zooming doesn't but goes in fixed 10% increments. Thus, you can zoom into all values between zoom.minPercent and zoom.maxPercent regardless of the zoomValues levels (I don't know if that's a bug or a feature, but that's what it does).

Comment 6

[rsx11m]

Testing with the current Firefox 19.0.2 release, the same applies here. With the Ctrl +/- keys one stays within the defined zoomValues stepping despite a larger range being allowed by zoom.{min,max}Percent. The old behavior was to simply apply fixed increments when leaving that range, similar to the Ctrl+mouse wheel now.

So it appears that we "inherited" this issue from the Toolkit implementation when switching to the per-site zoom management. The question is if it can be solved for SeaMonkey alone or if it would require to change that in Toolkit itself.

Confirming pending any change of the component moving this to Toolkit.

Comment 7

[FourthDr]

I've tried changing the toolkit.zoomManager.zoomValues and zoom.maxPercent settings in about:config, they have no effect. The only thing that allows zoom past 300% is (mouse wheel) + (control). :-( I tend to use the keyboard short cuts more and having to do something different with the mouse slows me down. Strange how something seemingly so simple turns out to be so difficult to fix. Why is that?

Comment 8

[FourthDr]

This still does not work. Anything over 300% is grayed out and the keyboard shortcut only goes to 300%. The mouse + Ctrl does go past 300%. But is would be much more useful to have the keyboard shortcut working. Any hope that this will be fixed in the near future? Seamonkey 2.33.1 still have the zoom limit problem. Would a fix-it bounty help? Say $50? Anyone??

Comment 9

[rsx11m]

Works for me when setting zoom.maxPercent to 800 and appending ",8" to toolkit.zoomManager.zoomValues, however I had to restart SeaMonkey for these values to be effective. Did you do that?

Comment 10

[FourthDr]

(In reply to rsx11m from comment #9)
> Works for me when setting zoom.maxPercent to 800 and appending ",8" to
> toolkit.zoomManager.zoomValues, however I had to restart SeaMonkey for these
> values to be effective. Did you do that?

Just tried that, and now (ctrl) + (+) hit tree times goes to 300 then jumps to 800 on the fourth! Not what I was looking for. Wasn't it suppose to zoom in 10% increments up to 800? At any rate, still doesn't work like before and people shouldn't have to look up obscure about:config settings for ever installation. A permanent fix should be worked into the release build which has not happened so far. Nice try.

Comment 11

[rsx11m]

Can you lose the attitude? Thanks.

The default stepping for Ctrl+/- is 0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4; thus, you are starting at 1 (100%) and a Ctrl+ brings you to 1.1 (110%), then 1.33 (133%), next 1.5 (150%), etc.
If I remember correctly there was a different spacing in earlier SeaMonkey versions which is carried forward in respective profiles, thus you hit the maximum after three Ctrl+ already.

Making it 0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,8 will proceed up to 240% and then 800% next as instructed. You can add an arbitrary number of intermediate values, and remove others if you don't like them. To get the behavior you'd like to see, you'd have to make it 0.3,0.4,0.5, ... ,7.8,7.9,8 with all intermediate 10% values. That's a feature/limitation (depending on your perspective) of the underlying toolkit code. SeaMonkey adds showing those values explicitly in the View > Zoom menu, for which a 10% stepping from 30% to 800% would probably be an overkill.

In contrast, the mouse wheel goes in 10% increments from zoom.minPercent to zoom.maxPercent, but that's an independent mechanism.

Whether or not these settings should be made accessible in the preferences somewhere or the defaults changed from the Toolkit definitions is a different question.

Comment 12

[FourthDr]

Thanks for your help. But it seems really clumsy and tedious to have to put a band-aid on something myself that should have been fixed 2 years ago? Same goes for ID:749908

How come Firefox works up to 800% using ctrl + (+)? and down to -600%?? I thought Seamonkey used the same engine? In theory Seamonkey should work the same as Firefox except for the extra stuff Firefox doesn't have like mail news etc.



(In reply to rsx11m from comment #11)
> Can you lose the attitude? Thanks.
> 
> The default stepping for Ctrl+/- is
> 0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4; thus, you are starting at 1
> (100%) and a Ctrl+ brings you to 1.1 (110%), then 1.33 (133%), next 1.5
> (150%), etc.
> If I remember correctly there was a different spacing in earlier SeaMonkey
> versions which is carried forward in respective profiles, thus you hit the
> maximum after three Ctrl+ already.
> 
> Making it 0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,8 will proceed up to
> 240% and then 800% next as instructed. You can add an arbitrary number of
> intermediate values, and remove others if you don't like them. To get the
> behavior you'd like to see, you'd have to make it 0.3,0.4,0.5, ...
> ,7.8,7.9,8 with all intermediate 10% values. That's a feature/limitation
> (depending on your perspective) of the underlying toolkit code. SeaMonkey
> adds showing those values explicitly in the View > Zoom menu, for which a
> 10% stepping from 30% to 800% would probably be an overkill.
> 
> In contrast, the mouse wheel goes in 10% increments from zoom.minPercent to
> zoom.maxPercent, but that's an independent mechanism.
> 
> Whether or not these settings should be made accessible in the preferences
> somewhere or the defaults changed from the Toolkit definitions is a
> different question.

Comment 13

[rsx11m]

(In reply to FourthDr from comment #12)
> How come Firefox works up to 800% using ctrl + (+)? and down to -600%?? I
> thought Seamonkey used the same engine? In theory Seamonkey should work the
> same as Firefox except for the extra stuff Firefox doesn't have like mail
> news etc.

Which version of Firefox are you comparing against? Both Firefox 31.6.0 and 36.0.4 are behaving the same as SeaMonkey 2.33.1 (not unexpectedly given that much of the underlying code is Toolkit). The only difference is the default stepping of .3,.5,.67,.8,.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3 in Firefox (SeaMonkey lacks the minimum and maximum settings, I think the reason being that there are no matching accesskeys in the View > Zoom menu, which Firefox doesn't provide and thus doesn't care).

So, with /current/ Firefox releases, setting zoom.maxPercent to 800 still won't allow to go beyond 300% zoom with the Ctrl+ keyboard shortcut. Hit Ctrl- once after reaching the maximum and you get exactly the same view as with the current SeaMonkey release.

(Quoting rsx11m from comment #4)
> Note that while the Ctrl +/- keys follow the levels defined in zoomValues,
> using Ctrl along with the mouse wheel for zooming doesn't but goes in fixed
> 10% increments. Thus, you can zoom into all values between zoom.minPercent
> and zoom.maxPercent regardless of the zoomValues levels (I don't know if
> that's a bug or a feature, but that's what it does).

There is now also bug 1138704, asking for the mouse wheel to obey the toolkit.zoomManager.zoomValues stepping as well. Thus, momentum rather goes into a direction opposite of what you are asking for...

So, either way, quite likely this would require a Toolkit/Core change in order to apply a default stepping beyond the pref's range until the zoom.{min,max}Percent boundaries are reached.

Comment 14

[FourthDr]

I tried the keyboard shortcut on both 36.0.4 and 31.6.0esr versions and it will zoom to +800%. No config changes where made. So Seamonkey is NOT working the same as Firefox.

> 
> Which version of Firefox are you comparing against? Both Firefox 31.6.0 and
> 36.0.4 are behaving the same as SeaMonkey 2.33.1 (not unexpectedly given
> that much of the underlying code is Toolkit). The only difference is the
> default stepping of .3,.5,.67,.8,.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3 in
> Firefox (SeaMonkey lacks the minimum and maximum settings, I think the
> reason being that there are no matching accesskeys in the View > Zoom menu,
> which Firefox doesn't provide and thus doesn't care).
> 
>

Comment 15

[rsx11m]

(In reply to FourthDr from comment #14)
> I tried the keyboard shortcut on both 36.0.4 and 31.6.0esr versions and it
> will zoom to +800%. No config changes where made.

Well, that's not what I see, neither on Windows nor on Linux, and definitely not what's intended by the code without at least zoom.maxPercent being modified. Thus, I'd expect /some/ customization of your Firefox installation or profile (code changes or add-on, maybe?) which may be possibly applied to your SeaMonkey profile as well.

Comment 16

[FourthDr]

(In reply to rsx11m from comment #15)
> (In reply to FourthDr from comment #14)
> > I tried the keyboard shortcut on both 36.0.4 and 31.6.0esr versions and it
> > will zoom to +800%. No config changes where made.
> 
> Well, that's not what I see, neither on Windows nor on Linux, and definitely
> not what's intended by the code without at least zoom.maxPercent being
> modified. Thus, I'd expect /some/ customization of your Firefox installation
> or profile (code changes or add-on, maybe?) which may be possibly applied to
> your SeaMonkey profile as well.

I'll try installing both versions 37 & 31.6 on a clean install of windows and see if I don't get the same result. I will let you know what I find out.

Comment 17

[FourthDr]

Sorry for the delay. I just install Firefox 37.0.2 on a clean system and I can ctrl+(+) 8 times and ctrl+(-) 5 time without any changes to the about:config settings. I also tried Firefox ESR 31.6 with the same results. Again, no about:config modifications where made. And since the system was a freshly loaded copy of Windows with anything else installed, it definitely can't be left over settings that allowed me to zoom in and out past 300%. Seamonkey does not behave the same as Firefox as far as the zoom function is concerned.

I request that the zoom keyboard shortcuts be fixed to at least mirror the same functionality that Firefox currently has by default. This functionality was present in Seamonkey up until about versions 2.0.14 and earlier.

Let me know if you would like me to test anything else. But I am pretty sure Seamonkey needs to be fixed to resolve this issue.

Comment 18

[rsx11m]

(In reply to FourthDr from comment #17)
> can ctrl+(+) 8 times and ctrl+(-) 5 time without any changes to the
> about:config settings.

So, your reading is that clicking 8x Ctrl/+ equals 800%? Well, it isn't, given that there are several intermediate zoom steps until 300% are reached. I'm counting those as well.

If you still doubt, make a screenshot of some page at normal view, then Ctrl/+ out to the maximum, make another screenshot and count the pixels. You should end up with 3x in Firefox and 2.4x for SeaMonkey (due to the lack of 3 being included in the default settings).

Thus, the only lack of parity with Firefox I can see here is that SeaMonkey doesn't include the 0.3x and 3x zoom levels in the default settings, otherwise the behavior is identical. Anything else is mostly Toolkit code anyway.

Comment 19

[rexyrexy2]

Perhaps we could give the Zoom menu items a separate pref (zoom.something?) from zoomValues, and give zoomValues more values, that way we don't crowd the zoom menu with tons of items? This would be even better than setting the +/- to strictly steps of 10..

The step size should increase as it gets higher, and decrease as it gets lower with Ctrl +/-. This makes sense because as you go higher, it gets less noticeable, and as you go lower, it gets more noticeable per percentage, and pressing keys so many times quickly becomes tedious. Example:

.01,.02,.03,.04,.07,.10,.15,.22,.33,0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3,4.5,6.75,10.13,15.19

the zoom values lower than 0.5 and higher than 240 were obtained from Mozilla 1.7. (Which has a minZoom of 1 and a maxZoom of 2000) They seemed like decent numbers for demonstration.

Comment 20

[Tony Mechelynck [:tonymec]]

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 SeaMonkey/2.44a1"
ID:20160208023510 en-US
c-c:4a60c0ffe9af0b68a82a6601c121e251863235e5
m-c:1cfe34ea394c66d7fa2c6dc366b05ab00e919113

When hitting Ctrl+Plus or Ctrl+Minus the zoom value goes stepwise along all the settings in toolkit.zoomManager.zoomValues (user set to "0.2,0.25,0.33,0.42,0.5,0.6,0.67,0.75,0.8,0.9,1,1.1,1.2,1.25,1.33,1.5,1.67,2,2.4,3,4,5"); when using View→Zoom→Other, which is preset to the previous non-original-size used IIUC, any value between zomm.minPercent (user set to 10) and zoom.maxPercent (user set to 1000) can be used. These are of course already "unrealistic" settings: at both ends of the range the text becomes unreadable, either because it is too small to be read or because only a very few letters are within the viewport.

Trying to set a value outside the min-max range greys out the OK button.

This behaviour seems acceptable to me; for large changes in zoom levels, rather than the keyboard, I would use the menu, which goes faster; for small changes, the keyboard, which allows smaller, reproducible steps.

Defaults are:
toolkit.zoomManager.zoomValues: 0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4
zoom.maxPercent: 300
zoom.minPercent: 30
which are IMHO good enough for "most" users, considering that those who need a wider range, or a different set of values, can use about:config.

A related question is: should there be an entry in the prefs dialog? and where? (a new subpage of Appearance maybe?) and what? (for min and max % a simple input box would do, but what about the set of values? O think an arithmetic sequence of values [i.e. constant difference] wouldn't be "right"; a geometric sequence [constant ratio between successive values] might be better; or maybe "simple" and "advanced" settings?)

I suppose the right solution is WONTFIX, but with user-doc somewhere… the mozillazine kb seems to have brought up-to-date since comment #2; I haven't checked sumo or MDN.

Comment 21

[rsx11m]

The rationale for the 0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4 scale was that it's close enough to what Firefox provides /and/ allows to provide a unique accesskey for each entry in the default menu (which is not an issue for Firefox as it doesn't provide individual menuitems for each level). The main difference is that the minimum (0.3) and maximum (3.0) values aren't included in the stepping and thus not selected by the CTRL +/- keyboard shortcuts.

Firefox mobile has 0.2,0.3,0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3,4 as default steppings, with zoom.minPercent=20 and zoom.maxPercent=400 (but not Firefox desktop).

A frequent use case for going well beyond 300% is to look at details in an image. However, pixelation and blurring occurs at /some/ point despite the underlying image library doing a great job. As another reference, afaict, Windows Photo Viewer doesn't scale beyond 300% in a slide show for small images.

If this is going to proceed anywhere, the following has to be kept in mind:

(1) in 0.3 and 3 are added to the default toolkit.zoomManager.zoomValues scale, we would have to add explicit accesskeys for the minimum and maximum zoom values;

(2) I'd agree with exposing zoom.{min,max}Percent but not toolkit.zoomManager.zoomValues in a prefpane, but then we'd need to provide a scale for a large expected range and may need to set limits for the zoom.{min,max}Percent boxes.

Something like 0.2,0.3,0.5,0.67,0.8,0.9,1,1.1,1.2,1.33,1.5,1.7,2,2.4,3,4,5,6,7,8 should work for 20-800% limits (assuming that going beyond an 8x zoom makes no sense even for images).

Comment 22

[rsx11m]

I'll give this a try, maybe splitting up into two parts (menu backend and extension of the zoom levels, followed by the min/max preferences UI).

Comment 23

[rsx11m]

Attachment: Proposed patch

This is a direct extension of the redesign made in bug 621823:

 - further zoom levels are preemptively added to cover the 20-800% range
   (I don't think it makes sense to add more levels than those);

 - since Firefox has now different levels and boundaries for their versions,
   I'm moving zoom.{min,max}Percent into browser-prefs.js as well;

 - if any of the levels matches zoom.{min,max}Percent they get a special label,
   thus allowing all default entries to have an access key (note that I'm not
   just using the first and last index, which may not match the pref values);

 - by default, 30-300% are now covered by Ctrl/+ and Ctrl/-, not just 50-240%;

 - subsequent entries enabled by modifying the boundaries may reshuffle the
   access keys 0-9 until they are all used (per original bug 621823 design);

 - exposing the zoom.{min,max}Percent prefs in the UI is bug 1251874.

Comment 24

[rsx11m]

Attachment: Screenshots: Default vs. Full Range

On the left-hand side of this screenshot, the default menu is shown open. It covers the same range as the current version, however has the 30% (Minimum) and 300% (Maximum) entries added. Accesskeys remain the same, and all entries remain covered despite extension of the levels, given the special "n" and "x" accesskeys for minimum and maximum.

On the right-hand side, zoom.minPercent is set to 20 and zoom.maxPercent to 800. In result, all remaining levels are available in the menu. Note that 30% is no longer the minimum, thus it "steals" the "3" accesskey from 133% in the default menu; also, all entries 300% and higher don't have an accesskey.

I was using "(Minimum Size)" and "(Maximum Size)" labels first for keeping them consistent, but they looked too long and too much "Size" in the overall picture.

Comment 25

[Philip Chee]

I was thinking:
400 % _F_our
500 % Fi_v_e
600 % _S_ix
700 % S_e_ven
800 % Eig_h_t

or just a b c d e | α β γ δ ε

Comment 26

[rsx11m]

I don't really like access keys which aren't in the label itself (and it would make the menu crowded having additional items on the right-hand side). Note that you can always navigate with the cursor to a specific menuitem, and those additional >300% ones aren't visible by default anyway.

Comment 27

[Ian Neal]

Comment on attachment 8724986 [details] [diff] [review]
Proposed patch

The images seem to show some of the access keys have changed, but I cannot see those changes in the patch or am I missing something?
Do we need to spread out the access keys a bit more?

Comment 28

[rsx11m]

The beauty of bug 621823 is that it assigns the accesskeys 0-9 automatically first-come/first-serve, thus they realign whenever the zoom levels are changed. There are only a few specific (original and double sizes) where we have dedicated letter access keys, to which I've now added minimum/maximum.

Spreading out the accesskeys isn't possible with the current design, i.e., would require to go back to fixed access keys (the question here being how to solve that given the possibly dynamic nature).

Comment 29

[rsx11m]

The code for dynamic assignment of the accesskeys is only partially in attachment 8724986 [details] [diff] [review], see http://mxr.mozilla.org/comm-central/source/suite/common/viewZoomOverlay.js#371

Comment 30

[rsx11m]

Ian, given that Neil is on leave, does this need a ui-review or can I remove it from his queue and mark the patch for check-in with your r+ only?

Comment 31

[rsx11m]

Comment on attachment 8724986 [details] [diff] [review]
Proposed patch

Redirecting ui-r? to Ratty per discussion in today's status meeting.

Comment 32

[Philip Chee]

Comment on attachment 8724986 [details] [diff] [review]
Proposed patch

>  - since Firefox has now different levels and boundaries for their versions,
>    I'm moving zoom.{min,max}Percent into browser-prefs.js as well;

> +pref("zoom.minPercent", "30");
> +pref("zoom.maxPercent", "300");

These two prefs are in all.js and Firefox doesn't override these. And now that we have UI in our Preferences window to adjust these values we don't really need to have our own default values.

Other than that ui-r=me

Comment 33

[rsx11m]

Attachment: Patch for checkin

Thanks, I'll push this as soon as I get commit access.

(In reply to Philip Chee from comment #32)
> These two prefs are in all.js and Firefox doesn't override these. And now
> that we have UI in our Preferences window to adjust these values we don't
> really need to have our own default values.

Ok, as long as they don't change those in the future beyond the 20-800% range (which appears unlikely) we should be fine and can still override them for suite/ in case it's changed in all.js.

Comment 34

[rsx11m]

Attachment: Unbitrotted patch

Pushed as http://hg.mozilla.org/comm-central/rev/b40a24089cd3