add-ons that set default zoom level will give unexpected results when Firefox becomes hidpi-aware on Windows

RESOLVED WONTFIX

Status

()

Firefox
Extension Compatibility
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: jfkthame, Assigned: jorgev)

Tracking

({addon-compat, regression})

22 Branch
x86
Windows 7
addon-compat, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox21 unaffected)

Details

(Reporter)

Description

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

Comment 1

4 years ago
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
Keywords: addon-compat
(Reporter)

Comment 2

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

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

Comment 4

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

4 years ago
(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?
tracking-firefox22: ? → +
Flags: needinfo?(jorge)
(Assignee)

Comment 6

4 years ago
(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
Flags: needinfo?(jorge)
(Reporter)

Comment 7

4 years ago
I've filed https://github.com/jtackaberry/nosquint/issues/75 about this.
(Reporter)

Comment 8

4 years ago
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.
Flags: needinfo?(alice0775)

Comment 9

4 years ago
I am waiting that Bug 851520 up lift to aurora22.0a2.
And then I will re-check the  migration code.
Flags: needinfo?(alice0775)
(Reporter)

Comment 10

4 years ago
OK, thanks. I've just nominated 851520 for uplift.
needsinfo on Alice to help with comment #9, since 851520 already landed on aurora.
Flags: needinfo?(alice0775)

Comment 12

4 years ago
(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)
Flags: needinfo?(alice0775)
(Reporter)

Comment 13

4 years ago
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?
Flags: needinfo?(jorge)
Assignee: nobody → jorge
(Assignee)

Comment 14

4 years ago
(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.
Flags: needinfo?(jorge)
(Reporter)

Comment 15

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

Comment 16

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

Comment 17

4 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Updated

4 years ago
tracking-firefox22: + → ---

Comment 18

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

Comment 19

4 years ago
On which add-on do you use fullZoom, and what for?

Comment 20

4 years ago
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?
(Assignee)

Comment 21

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.