+++ This bug was initially created as a clone of Bug #851520 +++
From comment #0 there:
Steps to reproduce:
This is new with the latest nightly build 22.0a1 (2013-03-15). I have a Windows 7 (x64) PC with a high-res (200dpi) monitor and therefore have set text size 200% in Window's Control Panel. With the 200% scaling, in most applications fonts appear at the same size as they would on a 100dpi monitor under normal scaling.
Therefore I would expect Firefox to work the same way, with the default zoom level (View->Zoom->Reset) giving pixel sizes twice those you'd normally get (where 'normal' is a computer with the Windows font size set at its default 100%).
However, in the latest nightly, the fonts are even bigger than would be expected. For example the Google home page is rendered so large that it doesn't fit horizontally even though the screen is 2400 physical pixels wide. I suspect that the 200% scaling is being double-counted somehow, so Firefox is now rendering everything at *four* times the number of pixels.
The user there had the Default FullZoom Level add-on configured for a default zoom of 200% (as a workaround for the lack of proper resolution-dependent scaling in Firefox). With the landing of hidpi support, this suddenly leads to 400% total scaling.
The patch in bug 851520 will fix this issue for the case where the zoom level is being remembered in Firefox content prefs (i.e., we normally restore the zoom when the user returns to a site where they had previously zoomed in manually). However, when an add-on such as Default FullZoom or NoSquint is used, the add-on will reimpose -its- zoom level, on top of the browser's default, and so the user still gets oversized pages.
To improve the user experience, we may want to reach out to authors of such add-ons and recommend adjustments.
(We could also consider "breaking" compatibility with them by modifying the API that is used to zoom, but this would disrupt valid use-cases for the zoom API in addition to fixing the problem cases.)
Following up on https://bugzilla.mozilla.org/show_bug.cgi?id=844604#c32:
Any add-on that sets the nsIMarkupDocumentViewer.fullZoom property is a candidate for closer examination as to why it's doing that and whether it should stop doing it, or at least adjust the zoom levels it's using.
For example, the Default FullZoom Level add-on does this in its ZoomManager.setZoomForBrowser method (among others) at:
and NoSquint does it in its zoom method at:
Alice0775, the Default FullZoom Level add-on is yours, I believe; would you consider updating it to recognize when the browser switches to hidpi support, and discard or scale down any saved zoom levels?
As soon as we have a decision in bug 851520 on the exact API we'll expose to JS, I think it should be possible for add-ons to handle this situation. If there's anything further you need on the Gecko platform side, please let us know so we can provide the best possible user experience during the transition.
Just FTR: on 2013-04-04, I emailed the author of NoSquint directly about this issue; have not had any response as yet.
I added migration code for hi-dpi display based on Bug 851520.
Thanks for working on this so promptly. One question - is there a bug in the test here?
It looks to me like it should be >= 10, not > 10, if I'm understanding the intention correctly.
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Just FTR: on 2013-04-04, I emailed the author of NoSquint directly about
> this issue; have not had any response as yet.
Jorge - would you happen to have better contact with NoSquint?
(In reply to Alex Keybl [:akeybl] from comment #5)
> (In reply to Jonathan Kew (:jfkthame) from comment #2)
> > Just FTR: on 2013-04-04, I emailed the author of NoSquint directly about
> > this issue; have not had any response as yet.
> Jorge - would you happen to have better contact with NoSquint?
His user address is the same as the one available for support. The add-on is actively being worked on, though. Maybe it would be a good idea to create an issue on his tracker: https://github.com/jtackaberry/nosquint/issues?page=1&state=open
I've filed https://github.com/jtackaberry/nosquint/issues/75 about this.
Alice0775, did you check the question raised in comment #4? I'm concerned the migration code in your add-on may not be quite correct.
I am waiting that Bug 851520 up lift to aurora22.0a2.
And then I will re-check the migration code.
OK, thanks. I've just nominated 851520 for uplift.
needsinfo on Alice to help with comment #9, since 851520 already landed on aurora.
(In reply to bhavana bajaj [:bajaj] from comment #11)
> needsinfo on Alice to help with comment #9, since 851520 already landed on
I have checked with aurora and released revised version of the addon(ver5.8)
Besides Alice's Default FullZoom Level add-on and Jason Tackaberry's NoSquint, are there other add-ons that people use to set a zoom level? Can we get help (from the AMO team? jorge?) to track down any other developers we should be reaching out to about this issue?
(In reply to Jonathan Kew (:jfkthame) from comment #13)
> Besides Alice's Default FullZoom Level add-on and Jason Tackaberry's
> NoSquint, are there other add-ons that people use to set a zoom level? Can
> we get help (from the AMO team? jorge?) to track down any other developers
> we should be reaching out to about this issue?
What code are we looking for that we know would break?
If I understand this correctly, bug 851520 should be flagged for addon-compat and we will notify add-on developers about it when we start looking into Firefox 22 compatibility (in a few weeks). If that's the case, this bug should be closed since we don't track individual add-on compatibility in Bugzilla.
(In reply to Jorge Villalobos [:jorgev] from comment #14)
> (In reply to Jonathan Kew (:jfkthame) from comment #13)
> > Besides Alice's Default FullZoom Level add-on and Jason Tackaberry's
> > NoSquint, are there other add-ons that people use to set a zoom level? Can
> > we get help (from the AMO team? jorge?) to track down any other developers
> > we should be reaching out to about this issue?
> What code are we looking for that we know would break?
See comment #1.
(Note that such add-on code won't "break", in the sense of throwing an error, failing to execute, etc.; the concern is that it will result in a poor/unexpected user experience because of the changed platform behavior.)
There are a few add-ons that appear to set this property, probably a dozen or more:
I flagges bug 851520 so that it is included in the compatibility communications.
Closing this, per comment #14 and comment #16 (noting I meant to say "flagged"). We will notify developer about this when we send the compatibility communications for Firefox 22, hopefully within the next couple of weeks.
What should we do to avoid th error while submitting the addon? I read all the comments on this page but couldn't quite understand what to do.
Error: Setting the `fullZoom` property can yield unexpected results in Gecko 22 and above.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=858185 for more information.
On which add-on do you use fullZoom, and what for?
We use it in CoolPreviews addon so the page auto-fits the preview window (which is usually smaller than regular window). We also give an option to the user to increase/decrease the zoom value.
(In reply to Jorge Villalobos [:jorgev] from comment #19)
> On which add-on do you use fullZoom, and what for?
If you're only using it for your preview window, I don't think it's a big problem. Any visual bugs will only affect that window and not the main content area. You should test that it looks good in various configurations, though.