1178138 - When using custom zoom levels, the displayed zoom level does not always correspond precisely with actual zoom level, and zooming in/out sometimes has no visual effect

Status: NEW

(Core :: General, defect)

Description

[eodmnyio]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150618135210

Steps to reproduce:

change toolkit.zoomManager.zoomValues to be in intervals of 1% for example

toolkit.zoomManager.zoomValues;0.3,0.5,0.67,0.8,0.9,1,1.01,1.02,1.03,1.04,1.05,1.06,1.07,1.08,1.09,1.1,1.11,1.12,1.13,1.14 

then use control + wheel up or control + "+"


Actual results:

firefox does not follow on those increments it skips some values for example it goes from 101 to 103% and then on higher levels it skips more like for example it goes from 138% to 142% or 191% to 198%


Expected results:

It should show an increased page size on each interval without skipping

Comment 1

[:Gijs (he/him)]

Can you reproduce this in an otherwise clean profile? Because I just tried to reproduce and I cannot. It seems to work fine all the way from 100% to 150%, and I gave up after that.

If you can, please copy/paste the entire pref value you're using here.

Comment 2

[iraola887]

Im eodmnyio changed my mail on github and bugzilla made me create an other account.

The issue was tested on a clean profile. I noticed i said control + wheel up actually that was wrong the issue happens with control + "+ " or using the menu control +  mouse wheel actually doesn't even read the values of the zoom preferences it uses firefox defaults i guess cause the increments are clearly not 1%. So there is an other bug.

This issue is still prevalent on firefox 40 dev latest version.

This is the value of the pref. I tested with shorter values but it's the same.

0.3,0.5,0.67,0.8,0.9,1,1.01,1.02,1.03,1.04,1.05,1.06,1.07,1.08,1.09,1.1,1.11,1.12,1.13,1.14,1.15,1.16,1.17,1.18,1.19,1.2,1.21,1.22,1.23,1.24,1.25,1.26,1.27,1.28,1.29,1.3,1.31,1.32,1.33,1.34,1.35,1.36,1.37,1.38,1.39,1.4,1.41,1.42,1.43,1.44,1.45,1.46,1.47,1.48,1.49,1.5,1.51,1.52,1.53,1.54,1.55,1.56,1.57,1.58,1.59,1.6,1.61,1.62,1.63,1.64,1.65,1.66,1.67,1.68,1.69,1.7,1.71,1.72,1.73,1.74,1.75,1.76,1.77,1.78,1.79,1.8,1.81,1.82,1.83,1.84,1.85,1.86,1.87,1.88,1.89,1.9,1.91,1.92,1.93,1.94,1.95,1.96,1.97,1.98,1.99,2,2.01,2.02,2.03,2.04,2.05,2.06,2.07,2.08,2.09,2.1,2.11,2.12,2.13,2.14,2.15,2.16,2.17,2.18,2.19,2.2,2.21,2.22,2.23,2.24,2.25,2.26,2.27,2.28,2.29,2.3,2.31,2.32,2.33,2.34,2.35,2.36,2.37,2.38,2.39,2.4,2.41,2.42,2.43,2.44,2.45,2.46,2.47,2.48,2.49,2.5,2.51,2.52,2.53,2.54,2.55,2.56,2.57,2.58,2.59,2.6,2.61,2.62,2.63,2.64,2.65,2.66,2.67,2.68,2.69,2.7,2.71,2.72,2.73,2.74,2.75,2.76,2.77,2.78,2.79,2.8,2.81,2.82,2.83,2.84,2.85,2.86,2.87,2.88,2.89,2.9,2.91,2.92,2.93,2.94,2.95,2.96,2.97,2.98,2.99,3,3.01,3.02,3.03,3.04,3.05,3.06,3.07,3.08,3.09,3.1,3.11,3.12,3.13,3.14,3.15,3.16,3.17,3.18,3.19,3.2,3.21,3.22,3.23,3.24,3.25,3.26,3.27,3.28,3.29,3.3,3.31,3.32,3.33,3.34,3.35,3.36,3.37,3.38,3.39,3.4,3.41,3.42,3.43,3.44,3.45,3.46,3.47,3.48,3.49,3.5,3.51,3.52,3.53,3.54,3.55,3.56,3.57,3.58,3.59,3.6,3.61,3.62,3.63,3.64,3.65,3.66,3.67,3.68,3.69,3.7,3.71,3.72,3.73,3.74,3.75,3.76,3.77,3.78,3.79,3.8,3.81,3.82,3.83,3.84,3.85,3.86,3.87,3.88,3.89,3.9,3.91,3.92,3.93,3.94,3.95,3.96,3.97,3.98,3.99,4,4.01,4.02,4.03,4.04,4.05,4.06,4.07,4.08,4.09,4.1,4.11,4.12,4.13,4.14,4.15,4.16,4.17,4.18,4.19,4.2

Comment 3

[:Gijs (he/him)]

I still have trouble reproducing. On what page are you testing this? Is your Windows machine using hidpi (is the "make text or other items larger or smaller" preference in the control panel set to something other than 100%) ?

Drew, do you have ideas?

Comment 4

[Drew Willcoxon :adw]

I can't reproduce either using the pref from comment 2 and Firefox 40 dev edition.  Gijs, your question about hidpi is interesting.  Just looking at the code, I can't see how this kind of problem would happen, but if something is causing the browser's zoom level to not actually be what the zoom manager sets it to, then it could behave like that, and maybe hidpi is that something.

Comment 5

[Drew Willcoxon :adw]

(In reply to Drew Willcoxon :adw from comment #4)
> Just looking at the code...

The front-end zoom manager code, that is.  I have no idea what Gecko is doing underneath to actually set the zoom level of the document, which is what the front-end relies on.

Comment 6

[iraola887]

@Gijis

It should happen in any page I tested a ton of pages. On bugzilla comments now that you mention it I tested it and it seems to change on each tick cause the boxes move but if you look closely they don't resize. Test it in an other page like google .com if you don't notice what I'm saying on this page.

I checked and the hidpi is on predefined 100% I tested it on an other windows machine again on a clean profile and it happened there as well. You need to set the config on increments of 1% 1,1.01,1.02,1.03,1.04,1.05 etc
As soon as you try to go from 101% to 102% using control + "+" you'll notice no change same goes for 103 to 104 and in some big intervals for example from 191 to 196 you wont notice any change either.

Comment 7

[:Gijs (he/him)]

(In reply to iraola887 from comment #6)
> @Gijis
> 
> It should happen in any page I tested a ton of pages. On bugzilla comments
> now that you mention it I tested it and it seems to change on each tick
> cause the boxes move but if you look closely they don't resize. Test it in
> an other page like google .com if you don't notice what I'm saying on this
> page.
> 
> I checked and the hidpi is on predefined 100% I tested it on an other
> windows machine again on a clean profile and it happened there as well. You
> need to set the config on increments of 1% 1,1.01,1.02,1.03,1.04,1.05 etc

I have used your configuration as noted in comment #2, on both google's homepage and on bugzilla. It just seems to actually work for me while it isn't for you. I don't know why.

> As soon as you try to go from 101% to 102% using control + "+" you'll notice
> no change same goes for 103 to 104

This isn't really very surprising to me. A lot of items are small enough that that distinction will be meaningless after rounding, and where the size of large items is determined by the size of the smaller ones, the large items, too, will not resize because the smaller ones aren't...

Also, your comment #0 mentioned that if you go from 101% up, you end up on 103% immediately? But this comment seems to imply that you go from 101 to 102. Are you actually trying to say that while the percentage displayed updates correctly, your issue is that you don't see a difference in the page rendering?

> and in some big intervals for example
> from 191 to 196 you wont notice any change either.

That's the thing, I can't reproduce the big jumps.

Comment 8

[iraola887]

When you press control + "+" you should notice an increment each time you press it. Even if it's small it's going to be noticeable if you pay enough attention to it unless like you said firefox is rounding things down so it says "this wont be noticeable enough for you so I won't do anything" but if that were the case on the big jumps later on that shouldn't happen cause when it jumps the increase in size is huge unless the rounding is based on some weird code that fails to determine when it should or not be noticeable. 

Also if for example you change the option and set it of increments of 5% on the big jumps you'll notice it as well for example from 280 to 292 you'll have 2 ticks there that wont trigger any change (285 and 290).

I'm using windows 7 x64 are you using an other O.S. Maybe is windows 7 related issue? I haven't tested it on other O.S. other than W7 

My screen resolution is 1920*1080 do you have something that is a lot bigger or smaller than this

Is your res 4:3? maybe 16:9 affects firefox calculations somehow?

Comment 9

[iraola887]

Tested it on my sister's notebook res 1366*768 O.S. w7 x64. Same buggy results.

Hope this doesn't sound bad to you cause it's quite obvious but firefox has to be restarted for the toolkit.zoomManager.zoomValues setting to take effect maybe you forgot that if you tested it on the fly?

Comment 10

[:Gijs (he/him)]

(In reply to iraola887 from comment #9)
> Tested it on my sister's notebook res 1366*768 O.S. w7 x64. Same buggy
> results.
> 
> Hope this doesn't sound bad to you cause it's quite obvious but firefox has
> to be restarted for the toolkit.zoomManager.zoomValues setting to take
> effect maybe you forgot that if you tested it on the fly?

No.

(In reply to iraola887 from comment #8)
> Also if for example you change the option and set it of increments of 5% on
> the big jumps you'll notice it as well for example from 280 to 292 you'll
> have 2 ticks there that wont trigger any change (285 and 290).

I'm sorry, but I'm still having trouble following what you're saying. If you:

1) open the panel menu
2) right click the zoom control
3) click "move to toolbar"
4) hit ctrl +
(repeat step 4)

Are you saying that:

A) in some cases, the number in this control does not update correctly?
B) in some cases, the number updates but the page stays the same (until you have hit ctrl + several times)?

The distinction is really important and from the beginning this bug report sounded like you were saying (A). Now I think you might be saying (B). Please clarify.

Comment 11

[iraola887]

The number increases properly each time you press the combination or the buttons (if you use the wheel it goes up by 10%) but the content of the page does not increase with the zoom level increment on some levels. So when you see it go from 101 to 102 the page doesn't actually gets resized it just changes the number and the zoom level of 102 is skipped cause the increment on 103 is actually 3% bigger than the original size so you don't ever get the 102% zoom level in actual size you just see the number but no result. (I'm using the 101 to 102 examples but there are many skips and later on they become bigger than just 1% skipped like I said before)

Hope this clarifies sorry if it wasn't clear before. English is not my native language.

Comment 12

[:Gijs (he/him)]

Drew, can you offer more background and/or suggest core folks who know more about the layout/graphics side of page zoom so as to figure out what's up here, considering the revised understanding of what the issue is?

Comment 13

[Drew Willcoxon :adw]

OK, I also thought the problem was that the numeric zoom percentage wasn't properly changing.  I do see that pages don't visually change at every 1% interval.

Don't know who specifically to ask about it, but it's not a front-end bug, so let's move it.

Comment 14

[:Gijs (he/him)]

:kats, do you know and/or do you know someone who knows? :-)

Comment 15

[Botond Ballo [:botond]]

Full zoom affects the ratio between CSS pixels (what page content is measured in) and device pixels (what appears on screen (*)).

CSS pixels are subdivided into 60 app units. Layout represents sizes and positions in integer quantities of app units.

The value of the full zoom used for rendering is adjusted to be a value that makes the number of app units per device pixel an integer [1]. So, for example, if the full zoom is 1.5, the number of app units per device pixel is 60 / 1.5 = 40, which is an integer, so no adjustment is necessary. If the full zoom is 1.33, the number of app units per device pixel is 45.11, which is rounded to 45, yielding an effective full zoom of 1.33333333 to be used for rendering.

I believe it is this rounding that accounts for what you're seeing.

Note that this is not a regression. We've been doing this rounding since full zoom was introduced bug 4821 (at the time we were *truncating* rather than *rounding*, but same difference).

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/src/nsDeviceContext.cpp?rev=f57fc897b7bb#773


(*) There are other scales between device pixels and what actually appears on screen, but they're not important for the purpose of this bug.

Comment 16

[:Gijs (he/him)]

(In reply to Botond Ballo [:botond] from comment #15)
> Full zoom affects the ratio between CSS pixels (what page content is
> measured in) and device pixels (what appears on screen (*)).
> 
> CSS pixels are subdivided into 60 app units. Layout represents sizes and
> positions in integer quantities of app units.

Is changing the number of app units or their being integers at all feasible? :-)

If not, it sounds like this is wontfix/cantfix...

Comment 17

[Botond Ballo [:botond]]

(In reply to :Gijs Kruitbosch from comment #16)
> (In reply to Botond Ballo [:botond] from comment #15)
> > Full zoom affects the ratio between CSS pixels (what page content is
> > measured in) and device pixels (what appears on screen (*)).
> > 
> > CSS pixels are subdivided into 60 app units. Layout represents sizes and
> > positions in integer quantities of app units.
> 
> Is changing the number of app units or their being integers at all feasible?
> :-)
> 
> If not, it sounds like this is wontfix/cantfix...

Good question! I think Timothy might be in a better position to give an answer.

Comment 18

[Timothy Nikkel (:tnikkel)]

There is a define

http://mxr.mozilla.org/mozilla-central/source/gfx/src/nsCoord.h?rev=20729b28eb1e#29

that controls whether appunits are float or ints. But it's never been turned on in production code AFAIK. Changing it would likely involve a lot of work.

Is there a compelling reason why we want to be able to zoom in exact increments of 1%? Skimming this bug I didn't see one.

Comment 19

[iraola887]

The issue is noticeable with 1% at the beginning but as the zoom level rises you can set higher increments and still notice it for example from 280 to 292 that's 12% increment so if you set increments of 10% for example you´ll be missing some "steps" as well. Not to talk about higher zoom levels like or from 388 to 414 that's a 26% increment.

Wouldn't at least be possible to set the way for an add-on to be able to deal with precise zoom if the team is not willing to invest time on this?

Comment 20

[Timothy Nikkel (:tnikkel)]

Changing the base unit that layout uses from int to float is something that happens at the very core of the browser, it is not something that an addon can do.

Comment 21

[Timothy Nikkel (:tnikkel)]

Can you explain why you feel that incrementing the zoom level in such small steps is important?

Comment 22

[iraola887]

Big or small is relative for me the increments become "big" at zoom levels 200%+ I personally use it to fit elements to the window size. If it's a huge ordeal to make it precise It doesn't need to be assigned to someone but if it's possible to leave it open so if anyone wants to take it they do I think would be for the best. I know the rounding makes things simpler but it ends up being kinda messy IMO.

Thanks for everybody's that participated time

Comment 23

[iraola887]

If the issue is increment relative to the previous increment that causes the issue what about implementing the ability on the zoom toolbar where it says the current zoom level to write any number you want and make it so when you press enter that it resizes the page calculated from 100% to that number you wrote so there is no issue and we can keep the rounding system and still get the precision when needed?

Comment 24

[iraola887]

Sorry to triple post but if there is a way to edit previous comments I couldn't find it.

Upon further testing I noticed that the previous comment wont solve a thing cause even if you set zoom levels like this 1,"a" or 1,"b" if "a" and "b" are on the same interval that has issues both even if they show a display change will end up displaying the same page size. For example if I set the config to 1,2.36 or 1,2.42 either of them will show the same size of the page so this is more of a serious problem now IMO cause you'll never know what actual zoom you really have at the moment. Firefox will round the zoom level and display a change but the size won't be the one specified will be something that can be 10% or even 20% off.

Comment 25

[Timothy Nikkel (:tnikkel)]

If you just want elements to exactly fill the viewport you could use the developer tools, right click the element, choose inspect element, then edit the css to make it the width you like. You could implement a greasemonkey script or addon to do it.

Comment 26

[iraola887]

At this point is more than what I desire to do with firefox the results ends up being confusing for the user. The user won't ever get the ability to get a desired zoom level +-1% zoom could acceptable but like I said it can end up being +-20% difference. If you don't want the user to be able to get a certain level of zoom but rather just make things bigger or smaller then don't give the user the option to specify the zoom level just let him press a key combination to make things bigger or smaller cause like this is confusing it's showing a number that is not representative at all of what's happening and also is confusing to specify "small" intervals and be pressing the key and not notice any change at all on the page size.

It may not be priority but I think is something that should be changed or at least be discussed with more people of the dev team.

Comment 27

[Timothy Nikkel (:tnikkel)]

Where do we let the user choose zoom in increments of 1%? (editing about:config doesn't count, as the warning when going to about:config says, that is done at your own risk)

Comment 28

[iraola887]

The title of this bug is wrong gijis changed it and I can't change it now cause I changed my mail on github and bugzilla made me do an other account. 


Is not needed to specify a 1% increment to notice this issue please don't get stuck with the 1% I thought I clarified that already many comments ago.


There are 2 issues:

 1) If you change the toolkit.zoomManager.zoomValues to be in increments of x% eventually you will end up with some increments not displaying any visual change on the page size. How many and how soon you find the missing increments will depend on how big the increment is.

2) Displayed zoom value most of the times is a lie. How far off from the real zoom value is depends how far from 100% you are.

Comment 29

[:Gijs (he/him)]

I've tried to clarify the title based on your two points.

The answer that tn is looking for, I expect, is, "we don't, outside about:config".

Considering the engineering effort and risk of changing our core layout units, the number of people this bug affects, and the severity of the bug, I don't think this bug itself is worth fixing. It may get fixed if we ever decide to switch the basic app units or reimplement page zoom for other reasons. I'll leave :tn to make a decision.

Comment 30

[Timothy Nikkel (:tnikkel)]

I'd agree with comment 29.