844604 - Text is too small on hidpi displays

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Jim Mathies [:jimm]]

Attachment: screenshot

See screen shot.

Comment 1

[Masatoshi Kimura [:emk]]

IE changes the default zoom level automatically. For example, if the dpi is 144, default zoom level will be 150%.

Comment 2

[Jonathan Kew [:jfkthame]]

What text size do you have selected in Windows' Display control panel (100%, 125%, 150%, other...)?

If you set layout.css.devPixelsPerPx to -1.0 in about:config, does that result in better text size?

Comment 3

[Jim Mathies [:jimm]]

Attachment: w/devPixelsPerPx setting = -1.0

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> What text size do you have selected in Windows' Display control panel (100%,
> 125%, 150%, other...)?

Testing on a Surface Pro, they set the default to 150%. 

> If you set layout.css.devPixelsPerPx to -1.0 in about:config, does that
> result in better text size?

Yes, in fact with this setting we get better google image art than ie.

Comment 4

[Jim Mathies [:jimm]]

filed bug 844795 on the fuzzy tab outlines.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: default to auto devPixelsPerPx setting on windows

I think we should go ahead and land this change on trunk, as it provides a clear improvement here (and see also bug 843790). There may well be other related issues we'll need to fix, but landing this in Nightly will help us to get those bugs clarified and filed. If we see problems that are too severe to ship this setting just yet, we could easily revert it on Aurora, but in my (limited) local testing the user experience seems much better with this setting than the current default.

Comment 6

[Jonathan Kew [:jfkthame]]

BTW, I pushed a tryserver job to confirm this doesn't break existing unit tests:
https://tbpl.mozilla.org/?tree=Try&rev=f6fe798cdd8a

Comment 7

[Jim Mathies [:jimm]]

On desktop this will fall through to the nsWindow calculation - 

http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#959

on metro it will default to 1.0. Is that what we want?

Comment 8

[Jonathan Kew [:jfkthame]]

No, but bug 816709 will fix that once it's ready.

Comment 9

[Jonathan Kew [:jfkthame]]

(And until then, it won't make any difference to what we have now.)

Comment 10

[Jim Mathies [:jimm]]

Comment on attachment 724172 [details] [diff] [review]
default to auto devPixelsPerPx setting on windows

Ok, sounds good.

Comment 11

[Jonathan Kew [:jfkthame]]

Pushed to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/281971e111cd

We know this will result in some "blurry" bitmap UI elements (see bug 844795), but IMO that's a minor problem compared to everything being too small. Getting this turned on will help motivate us to work on those issues :) as well as to flush out any other scaling-related bugs we need to fix.

Comment 12

[Greg Edwards]

Some of the artwork has already been done for OSX (see Bug 818940) and just needs to be dropped in.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is going to change the experience for a lot of users significantly --- I'd expect some blowback, just because people don't like change. So I suggest you announce this change as broadly as possible both inside and outside the Mozilla community.

Comment 14

[Justin Dolske [:Dolske]]

(In reply to Greg Edwards from comment #12)
> Some of the artwork has already been done for OSX (see Bug 818940) and just
> needs to be dropped in.

It's not quite that simple. While there are certainly a few things that share a common UI design across platforms, most stuff does not. Further complicating things is that Apple took the simple route of doubling (200%) the resolution for Retina displays, but Windows/Metro design guidelines recommend supporting both 140% and 180% scale factors.

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/281971e111cd

Comment 16

[Stephen Horlander [:shorlander]]

(In reply to Justin Dolske [:Dolske] from comment #14)
> (In reply to Greg Edwards from comment #12)
> > Some of the artwork has already been done for OSX (see Bug 818940) and just
> > needs to be dropped in.
> 
> It's not quite that simple. While there are certainly a few things that
> share a common UI design across platforms, most stuff does not. Further
> complicating things is that Apple took the simple route of doubling (200%)
> the resolution for Retina displays, but Windows/Metro design guidelines
> recommend supporting both 140% and 180% scale factors.

Also Windows 7 and Windows 8 Desktop use 125% and 150% scaling stops by default. With an additional option for customized scaling up to 200%. As best as I can tell anything that falls between the stops is just picking the largest closest option and downscaling it.

Comment 17

[Mark Hammond [:markh] [:mhammond]]

This had made the URL bar quite a bit uglier for me on Windows 7.  If you look at the 2 screenshots already attached to this bug, you will notice that the text size in the URL bar is the same in both cases.  However, in the second attachment (w/devPixelsPerPx setting = -1.0), the height has increased leading to additional whitespace in the address bar (above and below the URL) and ugly stretching of the icons to accommodate.

Personally, I'd rather stick with the old sizes here, but I expect the correct answer is that the text in the URL bar should be larger.

Comment 18

[Dão Gottwald [:dao]]

(In reply to Mark Hammond (:markh) from comment #17)
> This had made the URL bar quite a bit uglier for me on Windows 7.  If you
> look at the 2 screenshots already attached to this bug, you will notice that
> the text size in the URL bar is the same in both cases.  However, in the
> second attachment (w/devPixelsPerPx setting = -1.0), the height has
> increased leading to additional whitespace in the address bar (above and
> below the URL) and ugly stretching of the icons to accommodate.

In both cases, the text is larger than it would be at 96dpi. With the whole location bar enlarged, the ratio between the text and location bar height is about the same as it would be at 96dpi. In other words, the additional whitespace is expected.

Comment 19

[Jonathan Kew [:jfkthame]]

Actually, I think comment 17 is correct, and there -is- a bug with "system" font sizes in the chrome - we're not scaling them appropriately for the dpi. This becomes more obvious if you set devPixelsPerPx to something extreme like 3.0 (or a small value such as 0.25) - the URL bar, tabs, etc, become correspondingly taller (or shorter), but the actual font size stays unchanged.

The "original" screenshot here is in fact incorrect - we're using the font size that goes with 125% scaling, but the URL bar is *not* scaled to match, which is why the text looks rather crowded (especially below); the second screenshot shows correct rendering, but currently it is -only- correct if you use the system's dpi setting, it'll be wrong if you explicitly override to a different devPixelsPerPx setting.

I'll file a followup bug for this.

Comment 20

[Dão Gottwald [:dao]]

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> The "original" screenshot here is in fact incorrect - we're using the font
> size that goes with 125% scaling, but the URL bar is *not* scaled to match,
> which is why the text looks rather crowded (especially below);

Actually the location bar is enlarged there compared to 96dpi, but only so much that the enlarged text fits into it. That's expected behavior for layout.css.devPixelsPerPx == 1.0.

Comment 21

[Greg Edwards]

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> Actually, I think comment 17 is correct, and there -is- a bug with "system"
> font sizes in the chrome - we're not scaling them appropriately for the dpi.
> This becomes more obvious if you set devPixelsPerPx to something extreme
> like 3.0 (or a small value such as 0.25) - the URL bar, tabs, etc, become
> correspondingly taller (or shorter), but the actual font size stays
> unchanged.
> 
> The "original" screenshot here is in fact incorrect - we're using the font
> size that goes with 125% scaling, but the URL bar is *not* scaled to match,
> which is why the text looks rather crowded (especially below); the second
> screenshot shows correct rendering, but currently it is -only- correct if
> you use the system's dpi setting, it'll be wrong if you explicitly override
> to a different devPixelsPerPx setting.
> 
> I'll file a followup bug for this.

I think this is intended behaviour. The font sizes provided by the OS are in pixels and are being correctly interpreted as such. (The OS has already taken care of scaling these.)

Comment 22

[Jonathan Kew [:jfkthame]]

(In reply to Greg Edwards from comment #21)
> I think this is intended behaviour. The font sizes provided by the OS are in
> pixels and are being correctly interpreted as such. (The OS has already
> taken care of scaling these.)

The OS scales them for the system's "logical" dpi, but we need to apply additional scaling according to devPixelsPerPx if Firefox is -not- simply set to use the system dpi. See bug 852522.

Comment 23

[Greg Edwards]

On thinking about it, I agree. It makes using a scale very different from the system's work better.

Comment 24

[Jonathan Kew [:jfkthame]]

Nominating this for tracking-22 to ensure it is on release drivers' radar. Currently, this is -fixed- on mozilla-central, but there are some associated regressions; depending how far we get with resolving those issues, we may need to make a decision on whether to ship this or hold it back for a later cycle.

Whenever we do ship this - whether in FF22 or later - it is likely to provoke some reaction simply because it will cause a major change in behavior for users with hidpi displays and a >100% default scale in Windows. Until now, they've had to work around Firefox's lack of support for the Windows resolution scale by zooming pages - whether manually or using add-ons like Default-Zoom or NoSquint - and their experience will fundamentally change. So we need to be prepared for that, and have appropriate documentation/support/etc in place.

Comment 25

[Greg Edwards]

I agree. Also work needs to be started on the graphics. (I guess it doesn't have the same glamour as Retina on the Mac.)

Comment 26

[Jim Mathies [:jimm]]

(In reply to Greg Edwards from comment #25)
> I agree. Also work needs to be started on the graphics. (I guess it doesn't
> have the same glamour as Retina on the Mac.)

More of a resource constraints issue than anything else. Good application design artists are hard to find.

Comment 27

[Alex Keybl [:akeybl]]

We don't track new features (only regressions from those features) but I'll forward this on to support.

Comment 28

[Alex Keybl [:akeybl]]

(In reply to Jonathan Kew (:jfkthame) from comment #24)
> Whenever we do ship this - whether in FF22 or later - it is likely to
> provoke some reaction simply because it will cause a major change in
> behavior for users with hidpi displays and a >100% default scale in Windows.
> Until now, they've had to work around Firefox's lack of support for the
> Windows resolution scale by zooming pages - whether manually or using
> add-ons like Default-Zoom or NoSquint - and their experience will
> fundamentally change. So we need to be prepared for that, and have
> appropriate documentation/support/etc in place.

Can anything be done to mitigate that experience (zoom being completely off after update) rather than relying upon SUMO? If so, please file a bug and nominate that for tracking (we don't need to wait for negative feedback to flow in).

Comment 29

[Jonathan Kew [:jfkthame]]

I think there are a couple of issues here:

(1) Where the user has manually zoomed in to make pages readable, because we were ignoring the Windows DPI setting, and we now respect it (thus making everything bigger automatically) we can probably figure out some criteria whereby we ignore the saved zoom value and reset to 100%.

This is discussed in bug 851520 (already tracked; no patch yet, though), once we got past the presence of add-ons that further confuse the issue.


(2) Where the user has installed an add-on such as [1] or [2] (and there may well be others) that overrides the browser's default zoom level, I see several possibilities:

(a) Do nothing, except provide doc/support info advising people that if they've been using such an add-on to work around tiny text on a hi-dpi display, they probably need to remove it or at least adjust their settings. I don't have a good sense for what proportion of Windows users this would affect - it's essentially "all those whose Windows desktop resolution setting is >96dpi" - nor how many of them would react negatively ("hey, why is everything suddenly too big?") rather than positively ("finally, Firefox shows things at the proper size!") to the change.

(b) Reach out to the add-on authors to recommend that they detect the new Firefox version (how?) and make corresponding adjustments to any saved preferences. I'm not sure how feasible this is, but in theory it probably makes for the best user experience.

(c) Perhaps we could deliberately mark such add-ons as being incompatible with the Firefox version where the DPI-aware setting ships, so that they'll be disabled until upgraded. Though if the author updates the version info in the add-on but doesn't actually do anything about updating saved preferences, users would still suffer the "unexpected" zoom after updating it.

(d) A more extreme version of (c) would be to actually "break" the fullZoom API on nsIMarkupDocumentViewer (which, IIUC, is what the add-ons use to set the page zoom). We could make it a no-op if the system resolution is >96dpi, for example, and provide a new API (something like fullZoomDpiAware?) that add-ons can move to if they want to continue providing zoom functionality on hi-dpi systems. That would prevent "old" zooming add-ons affecting the user experience in new Firefox versions, and would help alert add-on authors that they need to reconsider the zoom settings they're offering.


[1] https://addons.mozilla.org/en-US/firefox/addon/default-fullzoom-level/
[2] https://addons.mozilla.org/en-US/firefox/addon/nosquint/

Comment 30

[Mark Hammond [:markh] [:mhammond]]

(In reply to Jonathan Kew (:jfkthame) from comment #29)
> I think there are a couple of issues here:
> 
> (1) Where the user has manually zoomed in to make pages readable, because we
> were ignoring the Windows DPI setting, and we now respect it (thus making
> everything bigger automatically) we can probably figure out some criteria
> whereby we ignore the saved zoom value and reset to 100%.

Similar to this is the case where the user has increased the default font size (ie, not per page, but globally).  It would be ideal if this pref could be reset (or at least scaled back) too.

> (d) A more extreme version of (c) would be to actually "break" the fullZoom API 
> on nsIMarkupDocumentViewer

<bikeshed>
If we ignore the complexity of implementation, another option might be that when the fullZoom API is invoked on a system with a non-default DPI setting, we allow the zoom to happen, but also display a notification panel saying something like "Is the text much larger than you expect?  Click here to explore fixing this", which takes them to a sumo page discussing the feature/problem and steps they can take to "fix" things.  Assuming most people will not have installed such addons in the first place, those who have are likely to be capable or reading and following such instructions.
</bikeshed>

Comment 31

[Alex Keybl [:akeybl]]

(In reply to Jonathan Kew (:jfkthame) from comment #29)
> (a) Do nothing, except provide doc/support info advising people that if
> they've been using such an add-on to work around tiny text on a hi-dpi
> display, they probably need to remove it or at least adjust their settings.
> I don't have a good sense for what proportion of Windows users this would
> affect - it's essentially "all those whose Windows desktop resolution
> setting is >96dpi" - nor how many of them would react negatively ("hey, why
> is everything suddenly too big?") rather than positively ("finally, Firefox
> shows things at the proper size!") to the change.

Adding dev-doc-needed keyword, regardless.

> (b) Reach out to the add-on authors to recommend that they detect the new
> Firefox version (how?) and make corresponding adjustments to any saved
> preferences. I'm not sure how feasible this is, but in theory it probably
> makes for the best user experience.

Let's start here, and then investigate (c) or (d). Adding add-on-compat keyword, and putting a needinfo on jorge to see how which major add-on developers use the fullZoom API.

Comment 32

[Jorge Villalobos [:jorgev] (he/him)]

Can someone point out what I should be looking for in add-on code?

Comment 33

[Alex Keybl [:akeybl]]

This bug has been listed as part of the Aurora 22 release notes in either [1], [2], or both. If you find any of the information or wording incorrect in the notes, please email [e-mail] asap. Thanks!

[1] https://www.mozilla.org/en-US/firefox/22.0a2/auroranotes/
[2] https://www.mozilla.org/en-US/mobile/22.0a2/auroranotes/

Comment 34

[Jonathan Kew [:jfkthame]]

(In reply to Jorge Villalobos [:jorgev] from comment #32)
> Can someone point out what I should be looking for in add-on code?

Let's move this to bug 858185, which I filed specifically about the add-on issues here.

(And bug 851520 addresses the issue for zoom levels "remembered" in Firefox's own content prefs.)

Comment 35

[Greg Edwards]

(In reply to Alex Keybl [:akeybl] from comment #33)
> This bug has been listed as part of the Aurora 22 release notes in either
> [1], [2], or both. If you find any of the information or wording incorrect
> in the notes, please email [e-mail] asap. Thanks!
> 
> [1] https://www.mozilla.org/en-US/firefox/22.0a2/auroranotes/
> [2] https://www.mozilla.org/en-US/mobile/22.0a2/auroranotes/

I would prefer the words "high DPI" or "high pixel density" instead of "high resolution" to distinguish them from 27 or 30" displays that run at a high resolution but do not use scaling.

Comment 36

[Drey]

Given that Mozilla making such drastic changes to zoom settings in FF22, i think it's a great opportunity to make Firefox more customizable and accessible.

Perhaps, a new switch should be added to preferences, titled "Default zoom level", that gives user choice:
(1) Use Operating System zoom setting (default)
(2) Use custom zoom level: (anynumber)%

That solves a few issues:
1. Users that didn't like new FF zoom handling, or using zoom addons, could easily switch back to 100% level.
2. Non-windows users would have an opportunity to set their desired zoom level until their OS zoom settings supported by Firefox
3. More customization/accessibility without need to install addons, as not everyone knows about them.

Should i file a separate bug for this?

Comment 37

[Jonathan Kew [:jfkthame]]

That would be a new feature, not part of this (resolved) bug, so yes, please file it separately if you'd like it to be considered. Whether we would actually do that sounds like a decision for the Firefox user interface folks.

Comment 39

[Jie Zhang]

There are many complaints about this feature in the Firefox Forum if you have not noticed them. I have to downgrade to 21 for now.

Comment 40

[Masatoshi Kimura [:emk]]

Rather, I had to use Firefox Beta until two days ago because Firefox <= 21 was effectively unusable on High DPI displays.

Comment 41

[Jie Zhang]

My setup is dual 19 inch LCD monitors, each one is 1280x1024, whose PPI is only 86, which I don't think are High DPI displays.

Comment 42

[Jonathan Kew [:jfkthame]]

(In reply to Jie Zhang from comment #41)
> My setup is dual 19 inch LCD monitors, each one is 1280x1024, whose PPI is
> only 86, which I don't think are High DPI displays.

In that case, I'd expect your Windows system DPI scaling to be left at 100%, and the rendering in Firefox 22 will be similar to FF 21 and earlier.

If your Windows DPI scaling factor is 125% (or more), then naturally everything - both in Firefox and elsewhere on your desktop - ought to be displayed rather large.

Comment 43

[Greg Edwards]

Attachment: How can people not read this?

Jie, you don't seem to understand what Windows DPI scaling is. Your screens certainly aren't high DPI but for some reason you chose to run them in a high DPI mode anyway--one designed to simulate 1024x819 resolution without DPI scaling. Then you depended on a bug which prevented your chosen DPI scale from being applied in Firefox. This same bug made Firefox 21 shrink to the size of a postage stamp on high DPI screens.

I would recommend dropping your Windows DPI back down to 96 and enlarging your font sizes. (Control panel / Personalization / Window Color / Advanced apppearance settings)

Comment 44

[Jie Zhang]

I didn't change the display settings in Windows 7. I use "Medium - 125% (default)". I guess most users use the default setting. If I change to "Smaller - 100%". The web page in Firefox might look normal (I have not tried it yet), but everything else will be too small.

Comment 45

[Greg Edwards]

Something is totally wrong with Windows if it auto-configures a 1280x1024 screen to 120DPI. This concerns me since it could affect other users who are running in a high DPI mode and have no idea why.

Comment 46

[Jie Zhang]

The machine I'm using is a laptop which has a 1920x1080 15 inch LCD screen. Maybe Windows did the auto-configure according to this screen instead of what I actually use now.

I also compared Firefox 21, IE 8 and the latest Chrome. All of them render the web pages in the same scale on my laptop. But for Firefox 22, I have to press "Ctrl -" twice to achieve the same effect.

Comment 47

[Mark Hammond [:markh] [:mhammond]]

(In reply to Jie Zhang from comment #46)
> The machine I'm using is a laptop which has a 1920x1080 15 inch LCD screen.
> Maybe Windows did the auto-configure according to this screen instead of
> what I actually use now.

Yeah, I think that is correct.  My 13" 1920x1080 laptop auto-configured this way too.

> I also compared Firefox 21, IE 8 and the latest Chrome. All of them render
> the web pages in the same scale on my laptop. But for Firefox 22, I have to
> press "Ctrl -" twice to achieve the same effect.

Is it possible you previously changed the "default font" preference in Firefox?  Due to the *lack* of this feature, I previously adjusted the default font size to be larger.  Then, when Fx 21 hit, I found the text was way too large because of this previous adjustment.  When I reverted that preference back to the default value (16), everything again looked correct.

Comment 48

[Greg Edwards]

I think now would be a good time to think about creating a high resolution icon set for Windows (Bug 878288) since fuzzy icons seems to be the leading complaint with Firefox 22.

It would be far more pragmatic to advise these unhappy users to install NoSquint and zoom out the pages than to get them to tweak devPixelsPerPx or (ghasp) roll back to an earlier Firefox version. Sharp icons (even if only 120DPI for now) are essential.

Comment 49

[Masatoshi Kimura [:emk]]

(In reply to Jie Zhang from comment #46)
> The machine I'm using is a laptop which has a 1920x1080 15 inch LCD screen.
> Maybe Windows did the auto-configure according to this screen instead of
> what I actually use now.

Yes, it is a very well known defect that Windows can't configure the DPI per monitor.

> I also compared Firefox 21, IE 8 and the latest Chrome. All of them render
> the web pages in the same scale on my laptop.

More precisely, on your external monitor.
They should be a bit too small on your 1920x1080 15 LCD, no?

Comment 50

[Masatoshi Kimura [:emk]]

(In reply to Jie Zhang from comment #44)
> I have not
> tried it yet),

Try, please.

> but everything else will be too small.

I bet they will not because Chrome and Firefox 21 will ignore system DPI settings. IE8 will remember the last zoom level (it should have set to 125% when the system DPI was 120).

Comment 51

[Greg Edwards]

A usability issue strikes me: when Windows is set to 150%, it's impossible to zoom the page out to device pixels, since that would be 66.6667% but the zoom goes in increments of 10%.

Comment 52

[Terrell Kelley]

(In reply to Masatoshi Kimura [:emk] from comment #40)
> Rather, I had to use Firefox Beta until two days ago because Firefox <= 21
> was effectively unusable on High DPI displays.

I find this quite dubious. No other browser (save IE on Windows 8) observes the Windows DPI settings, either. People have been getting along perfectly fine without this.

It's not as if the UI didn't scale. It was only webpages that would be tiny, and Firefox, like every other browser, has zoom buttons and settings to fix this. 

It's nice that Firefox now is automatically set to the same DPI as the system, but don't try to oversell it as some vital change. 

(Personally, I wish they'd just used the DPI to set the default zoom level, myself. That would have accomplished the same thing without breaking the settings everyone else uses. That's what Microsoft did.)

Comment 53

[Masatoshi Kimura [:emk]]

(In reply to Terrell Kelley from comment #52)
> (In reply to Masatoshi Kimura [:emk] from comment #40)
> > Rather, I had to use Firefox Beta until two days ago because Firefox <= 21
> > was effectively unusable on High DPI displays.
> 
> I find this quite dubious. No other browser (save IE on Windows 8) observes
> the Windows DPI settings, either. People have been getting along perfectly
> fine without this.

IE 10 on Windows 8 DO understand the DPI settings. It changes the zoom level by default. On my environment, it was 164%.
Even IE 8 on Win7 will do.
Chrome is also nearly unusable on High-DPI displays. People are complaining about that.
https://code.google.com/p/chromium/issues/detail?id=149881
Some other minor browsers may "work" if they don't tell a lie in the manifest.

> It's not as if the UI didn't scale. It was only webpages that would be tiny,
> and Firefox, like every other browser, has zoom buttons and settings to fix
> this. 

OK. By the same logic, all Jie have to do is zoom out for every site or change the hidden settings. Right?

Comment 54

[Greg Edwards]

Terrell: The reason this is a "new" issue is because it was only in the summer of last year when high DPI (> 200) laptops started coming to market. The method of only scaling text works okay on 120DPI systems but breaks down as the DPI continues to increase and it becomes obvious that images and UI chrome need to be upscaled as well.

This is essentially what the devPixelsPerPx setting does--scale up the entire UI rather than just text.

Windows 8.1 supports different DPI scales for different monitors. If Firefox continued to represent zooms in terms of device pixels, the browser would shrink and grow when moved between monitors.

"Stuff has suddenly become bigger after I upgrade" is actually a bug and is covered in Bug 858185.

Comment 55

[Greg Edwards]

Correction: Bug 851520 is where the main work on zoom migration was done.

Comment 56

[Jie Zhang]

(In reply to Masatoshi Kimura [:emk] from comment #50)
> (In reply to Jie Zhang from comment #44)
> > I have not
> > tried it yet),
> 
> Try, please.
> 
I have been using 100% for several weeks now.

> > but everything else will be too small.
> 
> I bet they will not because Chrome and Firefox 21 will ignore system DPI
> settings. IE8 will remember the last zoom level (it should have set to 125%
> when the system DPI was 120).

The fonts of Windows and other applications look smaller with 100%. But Firefox 22 renders page in almost the same size as Firefox 21 with 125%. After using it for several weeks, I think I have been used to 100% now. So this fixes the issue for me. Thank you.

Comment 57

[Peter Hozak]

I can't find a bug for an issue possibly caused by this fix - incorrect display of unicode characters in <title> (on tabs, in history, ...):

https://support.mozilla.org/en-US/questions/968277
http://superuser.com/q/633843/118860

Comment 58

[Greg Edwards]

I don't think that has anything to do with this bug. (The first reply looks automated and I've seen it in other Mozilla Support threads.)

I think in some fonts, the right facing triangle is really wiry, and there's slightly different font substitution rules for DWrite vs. GDI rendering.

ClearType (methods other than 5) do a really poor job with vertical antialiasing, further contributing to the distorted shape.

Comment 59

[Cresto]

(In reply to Drey from comment #36)
> Given that Mozilla making such drastic changes to zoom settings in FF22, i
> think it's a great opportunity to make Firefox more customizable and
> accessible.
> 
> Perhaps, a new switch should be added to preferences, titled "Default zoom
> level", that gives user choice:
> (1) Use Operating System zoom setting (default)
> (2) Use custom zoom level: (anynumber)%

I would definitely vote for this!

I am using the 125% Windows resolution scaling on a 1280x1024 TFT (yes, on purpose) with big fonts in Firefox and this "fix" brought me:

- blurry images
- rendering artifacts in spreadsheets
- oversized-icons and navigation-bar with rendering artifacts
- horizontal scroll-bars on some websites

So I would really appreciate an option to make Firefox ignore this "enforced zoom".

At the very least the "layout.css.devPixelsPerPx" should stay in the about:config menu and not be removed in the future like it happened for example to "browser.tabs.autoHide" (https://bugzilla.mozilla.org/show_bug.cgi?id=877479).

Although "layout.css.devPixelsPerPx = 1" only fixes the page rendering. The user interface and the "about:config"-page on the contrary get smaller because "layout.css.devPixelsPerPx" also disables the DPI-based user interface sizing.


PS: For all who want to restore the previous user interface size with "layout.css.devPixelsPerPx = 1" there is a work around:

Create inside your Firefox profile folder (see http://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data) a new folder "chrome" and then a file "userChrome.css" inside of this new folder.

Then write the following two lines into your "userChrome.css" file:


@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
* {font-size: 14px !important;}


Where  "font-size: 14px" defines the size of the letters of the Firefox UI (you can choose a bigger or smaller number if you want to change it).

Comment 60

[Greg Edwards]

Adding a default zoom level is being discussed in Bug 892888. I agree it needs much more attention than it's currently receiving. It's also IE and Chrome parity since they both have one. (even though Chrome isn't high DPI!)

99% of all user friction with high DPI would be relieved if a default zoom level were added. (QA please take notice!)