Last Comment Bug 858185 - add-ons that set default zoom level will give unexpected results when Firefox becomes hidpi-aware on Windows
: add-ons that set default zoom level will give unexpected results when Firefox...
Status: RESOLVED WONTFIX
: addon-compat, regression
Product: Firefox
Classification: Client Software
Component: Extension Compatibility (show other bugs)
: 22 Branch
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Jorge Villalobos [:jorgev]
:
Mentors:
Depends on: 851520
Blocks: 844604
  Show dependency treegraph
 
Reported: 2013-04-04 12:04 PDT by Jonathan Kew (:jfkthame)
Modified: 2013-06-24 14:46 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected


Attachments

Description Jonathan Kew (:jfkthame) 2013-04-04 12:04:28 PDT
+++ This bug was initially created as a clone of Bug #851520 +++

From comment #0 there:

<quote>

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%).


Actual results:

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.

</quote>

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.)
Comment 1 Jonathan Kew (:jfkthame) 2013-04-05 12:07:10 PDT
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:

https://addons.mozilla.org/en-US/firefox/files/browse/199550/file/chrome/defaultfullzoomlevel.jar/content/viewZoomOverlay8.js#L59

and NoSquint does it in its zoom method at:

https://addons.mozilla.org/en-US/firefox/files/browse/200892/file/chrome/nosquint.jar/content/browser.js#L425
Comment 2 Jonathan Kew (:jfkthame) 2013-04-08 08:27:24 PDT
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.
Comment 3 Alice0775 White 2013-04-09 17:08:23 PDT
I added migration code for hi-dpi display based on Bug 851520. 

https://addons.mozilla.org/en-US/firefox/addon/default-fullzoom-level/versions/?page=1#version-5.5
Comment 4 Jonathan Kew (:jfkthame) 2013-04-10 01:58:42 PDT
Thanks for working on this so promptly. One question - is there a bug in the test here?

https://addons.mozilla.org/en-US/firefox/files/browse/202800/file/chrome/defaultfullzoomlevel.jar/content/migration.js#L31

It looks to me like it should be >= 10, not > 10, if I'm understanding the intention correctly.
Comment 5 Alex Keybl [:akeybl] 2013-04-10 12:14:46 PDT
(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?
Comment 6 Jorge Villalobos [:jorgev] 2013-04-10 14:15:20 PDT
(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
Comment 7 Jonathan Kew (:jfkthame) 2013-04-13 09:35:00 PDT
I've filed https://github.com/jtackaberry/nosquint/issues/75 about this.
Comment 8 Jonathan Kew (:jfkthame) 2013-04-13 09:38:38 PDT
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.
Comment 9 Alice0775 White 2013-04-13 09:55:59 PDT
I am waiting that Bug 851520 up lift to aurora22.0a2.
And then I will re-check the  migration code.
Comment 10 Jonathan Kew (:jfkthame) 2013-04-13 10:13:04 PDT
OK, thanks. I've just nominated 851520 for uplift.
Comment 11 bhavana bajaj [:bajaj] 2013-04-24 13:09:50 PDT
needsinfo on Alice to help with comment #9, since 851520 already landed on aurora.
Comment 12 Alice0775 White 2013-04-24 13:44:42 PDT
(In reply to bhavana bajaj [:bajaj] from comment #11)
> needsinfo on Alice to help with comment #9, since 851520 already landed on
> aurora.

I have checked with aurora and released revised version of the addon(ver5.8)
Comment 13 Jonathan Kew (:jfkthame) 2013-04-24 13:56:46 PDT
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?
Comment 14 Jorge Villalobos [:jorgev] 2013-04-30 14:57:23 PDT
(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.
Comment 15 Jonathan Kew (:jfkthame) 2013-05-01 01:32:13 PDT
(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.)
Comment 16 Jorge Villalobos [:jorgev] 2013-05-02 12:55:33 PDT
There are a few add-ons that appear to set this property, probably a dozen or more:
https://mxr.mozilla.org/addons/search?string=.fullZoom&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=addons

I flagges bug 851520 so that it is included in the compatibility communications.
Comment 17 Jorge Villalobos [:jorgev] 2013-05-13 09:52:48 PDT
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.
Comment 18 Rahul Jonna 2013-06-18 15:56:00 PDT
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.
Comment 19 Jorge Villalobos [:jorgev] 2013-06-19 10:59:38 PDT
On which add-on do you use fullZoom, and what for?
Comment 20 Rahul Jonna 2013-06-19 11:13:13 PDT
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?
Comment 21 Jorge Villalobos [:jorgev] 2013-06-24 14:46:06 PDT
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.

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