See screen shot.

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

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?

(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.

filed bug 844795 on the fuzzy tab outlines.

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.

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

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?

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

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

Comment on attachment 724172 [details] [diff] [review] default to auto devPixelsPerPx setting on windows Ok, sounds good.

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.

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

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.

(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.

(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.

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.

(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.

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.

(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.

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

(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.

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

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.

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

(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.

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

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

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/

(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>

(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.

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

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 release-mgmt@mozilla.com asap. Thanks! [1] https://www.mozilla.org/en-US/firefox/22.0a2/auroranotes/ [2] https://www.mozilla.org/en-US/mobile/22.0a2/auroranotes/

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

(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 release-mgmt@mozilla.com 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.

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?

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.

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.

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

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

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)

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.

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.

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.

(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.

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.

(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?

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

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

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

(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?

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.

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

(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.

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

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.

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

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!)