Closed Bug 892888 Opened 11 years ago Closed 10 years ago
provide a "Default page zoom" option in Options
See bug 820679 comment 27, item 2. (And also bug 332275.) There are various add-ons (e.g. NoSquint, Default FullZoom Level, ...) that allow the user to set a default zoom level for pages. However, I think we should consider having this built in to the Options (Preferences) dialog, Content tab. In particular, this will provide a simple answer for users who are currently unhappy with the way the browser now respects the global Windows dpi scaling option, although we believe the new behavior is essentially correct, and is the most reasonable model for a future of increasingly high-resolution displays.
It may be worth mentioning that Chrome already has this built-in.
(In reply to Jonathan Kew (:jfkthame) from comment #0) > See bug 820679 comment 27, item 2. (And also bug 332275.) > > There are various add-ons (e.g. NoSquint, Default FullZoom Level, ...) that > allow the user to set a default zoom level for pages. However, I think we > should consider having this built in to the Options (Preferences) dialog, > Content tab. > > In particular, this will provide a simple answer for users who are currently > unhappy with the way the browser now respects the global Windows dpi scaling > option, although we believe the new behavior is essentially correct, and is > the most reasonable model for a future of increasingly high-resolution > displays. The crucial moment is the next one: “users who are currently unhappy” and to make it more precise, it should read “many users who are currently unhappy”. It is opposite of “although we believe the new behavior is essentially correct”. Nothing that make many users "unhappy” can be correct! I’d like to see more savable setting in e-mail client (save zoom level for example) but default web-pages zoom should never be linked with Windows (7) display setting. 125% is excellent for me (for Windows 7) but Mozilla Seamonkey (stand-alone!) should not be linked with that.
Windows DPI settings are meant to work in a way that simulates a lower resolution but with more pixels. This article explains in more detail: http://blogs.msdn.com/b/b8/archive/2012/03/21/scaling-to-different-screens.aspx (Skip to the "different pixel densities" section.) Consider the following example: You have three different 15" screens: One is 1280x720, one is 1920x1080, and the last is 2560x1440. The goal of DPI scaling is to make objects onscreen appear the same size on all three screens. In the old days, you would make objects the same size by setting all of them to a low resolution like 1280x720, but this defeats the purpose of even having the higher resolution screens to begin with. Running them at a higher resolution makes everything too small. DPI scaling solves this problem by running at the highest possible resolution anyway and uses those extra pixels to make objects smoother and sharper. The problem is this: Many Windows applications were designed under the assumption that DPI scaling would never be used. They lay themselves out in terms of pixels, so they become smaller on high resolution screens in spite of DPI settings. (Firefox 21 was an example.) Even worse, however, is that users like yourself came to expect applications to have DPI scaling bugs--specifically that only text sizes would change, creating a huge problem for the developers who want to fix those bugs. There's an even bigger problem: extremely high resolution laptop screens are showing up. The Retina MacBook Pro was the first example but now there's the Toshiba Kirabook and a bunch of 3200x1800 15" laptops are about to hit the market. If we go back to Firefox 21's buggy scaling, Firefox is entirely unusable on those devices--icons, tabs, and pages are much too small. It's only going to get worse from here as those screens become cheaper and they head into larger form factors like the desktop (4K). It's only a matter of time before they outnumber the 120DPI-on-96DPI-monitor users. Clearly moving ahead with technically correct DPI scaling is the best long-term choice right now, even if it makes some users unhappy. Addressing those users' concerns is what bugs like this one are for.
OK Greg: I see your point. But, anyway: I think that problem have to be divided in two separate components: application and web-pages content. Let developer decide what and how they will do with high def screens and monitors. My complain was only about pages content – not application look.
Then you have come to the right place: that's exactly what this bug is requesting.
I think I misunderstood that bit about "developers". You mean website owners? Expecting them to provide zoom on their own is hopelessly optimistic and reminiscent of what Microsoft did with Windows XP, getting us into this whole DPI mess to begin with. Let me say it plainly: web developers wouldn't implement DPI scaling hardly ever if it was up to them. Most of them would make sites that look good on their screens and stop there. (The W3C learned this the hard way and had to effectively abandon the px unit as representing pixels and instead fixed it to 1.33pt.) Luckily for us, it's not up to them. The current web standards leave it up to the browser to pick an appropriate zoom level and scale the entire site by that factor. Web developers who are actually aware of high DPI can then provide sharper images by using media queries or window.devicePixelRatio to discover the screen's zoom.
+ 1 For the "Default page zoom option". I am using the 125% Windows resolution scaling on a 1280x1024 TFT (yes, on purpose) with big fonts in Firefox and the new "enforced zoom" brought me: - blurry images - rendering artifacts in spreadsheets - oversized-icons and navigation-bar with rendering artifacts - horizontal scroll-bars on some websites I would appreciate a "Default page zoom option" especially since I fear otherwise the current work around with about:config "layout.css.devPixelsPerPx = 1" will otherwise disappear completely like many other things that got first pushed to about:config and then were removed completely. Also "layout.css.devPixelsPerPx = 1" does not the complete job since it only fixes the page rendering and you still have to fiddle with your profile's "userChrome.css" file to restore the bigger font size of the Firefox user interface. (In reply to Greg Edwards from comment #6) > Web developers who are actually aware of high DPI can then > provide sharper images by using media queries or window.devicePixelRatio to > discover the screen's zoom. They can. But most websites I visit just got one set of images for everything and the new Firefox enforced zoom therefore results in images getting blurry.
+1 to "Default page zoom option". +1 to Firefox notify the user the first time it runs on a display with dpi!=96 about scaling issues and let them decide. Browser UI is one thing, and should be handled separately. If all UI elements are vector (ie. SVG) then UI scaling artifacts won't be so much of a problem. Web content, which is what this bug refers to, must be handled separately. While it may be acceptable for some users, especially simple users that only read content and don't mind visual artifacts, it is unacceptable for many others, especially if the graphic design is important, scaling artifacts are a no-no. I have reported https://bugzilla.mozilla.org/show_bug.cgi?id=980338 when I realized the horror of it, and the maximum confusion it gave me. I kept exchanging print screens with both client and designer and they didn't correspond. The images that is. Until I made the cross browser comparison. While small text on hires display as described here https://bugzilla.mozilla.org/show_bug.cgi?id=844604 , including UI, is a problem, distorting content is not a proper solution. And reporting that an image is 960 pixels wide when it is displayed as 1200 pixels is another big issue. Image Pixels is a precise unit, regardless of W3C messing with CSS px definition. I believe there was a very good reason to have in FF the option: view->zoom->zoom text only. Only this was negated by the new behaviour to upscale everything regardless. I agree with Cresto's comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=844604#c59 as the "fix" in question has brought the same problems. Vector content scales well. Bitmap content does not. Images are bitmaps. Content gets distorted. Please provide a fix and please alert user and please let user choose.
(In reply to Andrei Boros from comment #8) > I believe there was a very good reason to have in FF the option: > view->zoom->zoom text only. It still breaks quite some websites. > Please provide a fix and please alert user and please let user choose. The majority of users might not understand or not care. The trend is to move away from as many alerts as possible.
A one-time alert at FF first running on "large fonts" could hardly be considered "many alerts". It falls into the same class as "do you want FF to be your default browser" ...
Bug 332275 is about the same topic. One of these reports should be marked as a duplicate of the other.
Since bug 332275 has a draft patch and several duplicates already, that's an easy call.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.