Separate UI and Content DPI scaling in about:config

NEW
Unassigned

Status

()

Core
Layout: View Rendering
5 years ago
5 years ago

People

(Reporter: JDev, Unassigned)

Tracking

22 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

With the change in FF22 to adjust for default scaling many are setting layout.css.devPixelsPerPx to 1.0 to restore content to it's previous appearance due to blurry images & content scaling issues.  Unfortunately adjusting the content in this way also forces the UI into the same state.  These ought to be separate from each other to allow the UI to remain consistent with the system defaults while allowing the user to control the default scaling of their content.
(Reporter)

Updated

5 years ago
Component: Untriaged → Layout: View Rendering
OS: Windows 8 → All
Product: Firefox → Core
Hardware: x86_64 → All
NoSquint would do the job.
(Reporter)

Comment 2

5 years ago
While NoSquint does allow for a close approximation it is not a solution that is viable for web developers who need the true 100% content size but operate on non-100% scale.

Comment 3

5 years ago
Also, the NoSquint add-on is available for Firefox only but not (or no longer) for other Gecko applications like Thunderbird or SeaMonkey.
In any case, I don't understand why the separate DPI settings is needed. It's sufficient to adjust the content zoom, and it's what other browsers (at least IE) do.

Comment 5

5 years ago
Almost. Sure, one could optimize the layout.css.devPixelsPerPx value for the UI elements and use the zoom level to provide an offset for the content as desired, the problem being that there is no way to specify a /default/ zoom level (which is always 100% - forcing it to a different value with a zoom.{min,max}Percent hack won't work in Firefox due to bug 539417).

I'm not sure if additional tweaking of layout.css.dpi could be used to enforce an offset between chrome and content scaling (and it still doesn't appear to do anything on Windows platforms) thus it could serve as a workaround.
(Reporter)

Comment 6

5 years ago
Here's my use case which NoSquint does not correctly adjust for:

2560x1600px resolution on a 30" monitor and system set to 150% of norm.  

As a developer I don't care about what the content says so I don't need to see the text - I do need to see the page overall, how things are wrapping, etc.  Due to the way NoSquint works there will be rounding adjustments which affect the final computed values which change the final look.  Not by much but even a 1px difference can cause issues in a design (ie: cause an image to wrap differently).  This is something that the browser should be able to handle without a plugin.
(In reply to Mark from comment #6)
> Not by much but even a 1px difference can cause issues in a design (ie: cause an image to wrap differently).

The design is fundamentally flawed.
(Reporter)

Comment 8

5 years ago
That's a matter of opinion, however, I would point out that just because a dev is required to work with a set of limitations doesn't mean the browser should further limit you.  I cannot tell you the number of flawed designs I've inherited from high school amateurs. I digress...

That particular dev use case aside, UI scalling and content scaling still ought to be separated for consistency between system elements and expected content output.  Zoom hacks do not provide a consistent experience for varying expectations of content sizing.
I found IE 11's devicePixelRatio returned the current zoom level. It would be better to follow that, so the Webpage can choose the most appropriate asset.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

5 years ago
I have my Windows 7 at 115% DPI, so I'm one of those affected by the scaling update on version 22. I tried to turn off this new scaling feature by setting layout.css.devPixelsPerPx to 1.0, mainly to get rid of the upscaled and blurred images that are present both on the web content and UI elements (like the favicons on the bookmark toolbar), but then I faced an utterly reduced UI (which has obviously a reduced usability).

With Firefox 21 though, the UI was not so tiny (and at the same time images were not blurred). So supposing the tiny UI on FF22 is the default size (the no-zoom-at-all look), what made the UI bigger on FF21 (which had no system-like-scaling feature)? Was it because of my 115% config on Windows? Is it possible to revert to FF21 behaviour somewhere in the configs?

Comment 11

5 years ago
Comment #10 is a rather common experience also seen in the forums. Gecko 21.0 and earlier applied the 125% display setting on Windows for chrome (UI) fonts while rendering icons and content in 100% (again producing a problem caused by the lack of a user-specifiable default zoom level given that those users had problems to get an equally larger size of the content beyond font size for a proportional scaling of formatting and images, so that wasn't an optimal solution either).

You could set layout.css.devPixelsPerPx to 1.0 and then create userChrome.css rules to apply larger fonts for menus and other UI labels.

Comment 12

5 years ago
comment 11 I see, thanks for clarifying. Nevertheless, I think the suggested solution to this problem (diving in settings and config files) is far from ideal, and definitely not accessible to the casual user (which I suppose represents the larger portion of the userbase).

In my opinion such behaviour is just bad design. Both IE and Chrome separate their UI from the content, so that zooming affects only the content (leaving the UI out of it). I think that's the correct approach.

Comment 13

5 years ago
I agree that userChrome.css hacks aren't a suitable configuration option for "normal" users, especially given that the selectors here may be complex. Separating layout.css.devPixelsPerPx for chrome vs. content wouldn't resolve the issue you mentioned in comment #10 of the icons being presented at 100% while the labels are shown at 125%. That would require a third preference setting, either separating chrome labels from other chrome UI or similar to the content's text-zoom option to scale text but not images.
You need to log in before you can comment on or make changes to this bug.