1022006 - zooming on desktop should not affect screen properties

Status: NEW

(Core :: DOM: Core & HTML, defect, P2)

Description

[hexalys]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.59.10 (KHTML, like Gecko) Version/5.1.9 Safari/534.59.10

Steps to reproduce:

1. Visit: http://www.whatismyscreenresolution.com/
2. Zoom-in (Ctrl+ of ⌘+ for Mac) or out (Ctrl- of ⌘- for Mac) and reload the page.


Actual results:

The screen size, window.screenX, window.screenY and window.outerWidth change proportionally to the zoom ratio (and by relation the window.devicePixelRatio)

To observe the full changes of other screen related properties visit this page http://htmldoodads.appspot.com/dimensions.html and zoom in or out.
All screen properties will wrongly change (dynamically) as you zoom out of 100%.


Expected results:

Screen size is independent from the viewport (especially on Desktop).

From a usage standpoint this incurs a wrong read of screen-size from screen.width and screen.height.

A practical use case affected by this is if you open a new window while zoomed in.
The window opens at a much bigger size than a given pixel size, considering it relies upon window.screenX, window.screenY, and window.screen values in relation to the actual screen.

For example when zoomed in at 200% a Facebook login popup (from a like button click when logged off Facebook) will open twice a big as initially intended. A new window shall be dependent upon accurate screen size values.

This issue also prevent from detecting as to wether a user has zoomed in or not in a straight forward fashion.

Screen properties should remain unaffected by the browser viewport here, including 'window.outerWidth', which technically "represents the width of the whole browser window including sidebar". window.outerwidth being a reference of the "window size" in relation to the screen, but not the viewport, unlike window.innerWidth.

PS: I think the change occurred with Firefox 18 along the changes with the devicePixelRatio value reflecting the manual zoom ratio. I have not tested though.

Comment 1

[hexalys]

For reference, IE does the same as Firefox (Since Netscape), as described by PPK:
"screen.width and screen.height [...] Should not change when the browser is zoomed."
http://www.quirksmode.org/mobile/tableViewport_desktop.html

Comment 2

[Markus Stange [:mstange]]

The way it currently works in Firefox has at least one advantage: screen.width * window.devicePixelRatio always gives the number of physical device pixels that the screen has. For example, my "retina" Macbook Pro has a physical screen resolution of 2880x1800, and for pages that are not zoomed, devicePixelRatio is 2 and screen.width is 1440. How would you get the value 2880 if the page is zoomed to, say 110% (=> window.devicePixelRatio == 2.2) and screen.width was still 1440? window.devicePixelRatio is affected by zoom, and I think that's a very desirable property.

(In reply to Bruno R. from comment #0)
> A practical use case affected by this is if you open a new window while
> zoomed in.
> The window opens at a much bigger size than a given pixel size,

So that means that our window open code doesn't interpret the given size as CSS pixels relative to the opening page. If it did, would that solve this particular problem? I think it would.

Comment 3

[hexalys]

(In reply to Markus Stange [:mstange] from comment #2)
> The way it currently works in Firefox has at least one advantage:
> screen.width * window.devicePixelRatio always gives the number of physical
> device pixels that the screen has. 

You can always detect that with window.outerWidth if made accurate to its mozilla definition:
https://developer.mozilla.org/en-US/docs/Web/API/Window.outerWidth

> For example, my "retina" Macbook Pro has
> a physical screen resolution of 2880x1800, and for pages that are not
> zoomed, devicePixelRatio is 2 and screen.width is 1440. How would you get
> the value 2880 if the page is zoomed to, say 110% (=>
> window.devicePixelRatio == 2.2) and screen.width was still 1440?
> window.devicePixelRatio is affected by zoom, and I think that's a very
> desirable property.

Equally if you are on a 2880 non-retina screen and zoomed 200% you do get 1440 from your example. Meaning you can't detect whether you are zoomed 200% or wether you are on 2880 retina display. That's the confusing and misleading issue affected by the devicePixelRatio change.

> (In reply to Bruno R. from comment #0)
> > A practical use case affected by this is if you open a new window while
> > zoomed in.
> > The window opens at a much bigger size than a given pixel size,
> 
> So that means that our window open code doesn't interpret the given size as
> CSS pixels relative to the opening page. If it did, would that solve this
> particular problem? I think it would.

I wouldn't solve the ability to detect as to wether the user is zoomed, my main case here.

Having the zoom affect the devicePixelRatio is the correct path. But alternatively, we need a method to discern manual zoom from screen ratio to be able to assess the difference.

On Webkit, you can compare window.outerWidth with window.innerWidth to give you a zoom scale that the viewport is zoomed. window.outerWidth always being in screen pixels as per the 'unspecced' definition of window.outerWidth. But sadly Firefox and IE rescale window.outerWidth too when zooming.

window.outerwidth is a key here along with respecting screen sizes to be able to both accurately detect or calculate the retina screen size and zoom detection. I think it's a more proper approach.

IE has an alternative to detect zoom scale with screen.deviceXDPI / screen.systemXDPI. With Webkit you can detect an 'element.svg.currentScale' to give an accurate zoom ratio. But sadly neither of these method are usable on Firefox. I don't know SVG enough to assess how critical is that lack of currentScale return for SVG, but I suspect that may also be a use case affected by the current screen API values and current window.outerWidth discrepancy.

My preference is for both IE and Firefox to match Webkit for such consistency, as I agree with PPK's assessment that it is incorrect for the browser to give inaccurate screen values in the first place.

Comment 4

[Glenn Linderman]

This seems to be an area where standards and common definitions are lacking and/or misinterpreted.

As a web designer, I want my designs to work on everything from small, low-res screens, to small, hi-res screens, to large, low-res screens, to large, hi-res screens.

It's always been hard to achieve that, and now there are more variations, and greater mixes of text and graphics.

There have been lots of sites designed assuming the browser window was always maximized. There have been lots of sites designed assuming the browser viewport is 900 or 1200 pixels wide. These are stupid assumptions, but the problem was, and still is, that it is hard to get good information about what the real screen size is, and what the real dpi is.

Rather than provide decent information to the web designer about the real dpi, "CSS pixels" were invented. As a transitional technique for existing designs on higher resolution displays, it isn't a bad technique. But exposing reality is a good idea too, so that appropriately sized bitmaps can be served, and appropriately scaled vector graphics can avoid being pixelated, or text kerned based on fat pixels when skinny pixels are available (a problem I'm having right now in attempting to deal with the variant resolution between screens and printers, and have things actually look right).

In sum, abstractions are useful, but hiding information causes problems.

Comment 5

[Vlad Bacia-Mociran [:VladB]]

I didn't managed to reproduce this issue on the latest release(43.0.4) nor the latest Nightly(46.0a1).

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160110030214

Can you please try to reproduce this on the latest release(43.0.4) and latest Nightly(46.0a1) and provide the results?
When doing this, you could create a new clean Firefox profile, or maybe test in safe mode, as some of this issues may be caused by third party installed addons or custom settings
(https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thank you,
Vlad

Comment 6

[YF (Yang)]

WFM on 31.0a1 (2014-04-28) & Fx44b7 Win10.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I don't know how it can possible "wfm", because this is obviously the behavior of the screen getters and the window.outerWidth getter: they return values in CSS pixels, and zooming changes the size of a CSS pixel.  

> A practical use case affected by this is if you open a new window while zoomed in.

Hmm.  I wonder how we actually do the CSS to device pixel conversion there and why it's ignoring the zoom level...  Seems like the right thing is to take zoom into account there.

I guess comment 2 already said all that...

roc, thoughts?  Seems to me like we should just fix the window.open feature stuff to work right here.

Comment 8

[YF (Yang)]

(In reply to Boris Zbarsky [:bz] from comment #7)
> I don't know how it can possible "wfm", because this is obviously the
> behavior of the screen getters and the window.outerWidth getter: they return
> values in CSS pixels, and zooming changes the size of a CSS pixel.  

sorry, I misinterpreted as the shown of http://www.whatismyscreenresolution.com/.

Comment 9

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

(In reply to Boris Zbarsky [:bz] from comment #7)
> roc, thoughts?  Seems to me like we should just fix the window.open feature
> stuff to work right here.

I agree, that's a bug we should fix and it would fix this bug as filed.

It might also make sense to introduce a standardized property that lets authors decompose devicePixelRatio into user zoom and screen DPI, i.e. expose one of user zoom or screen DPI explicitly, but that's really a standards issue and should be decided in www-style.

Comment 10

[hexalys]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9)
> (In reply to Boris Zbarsky [:bz] from comment #7)
> > roc, thoughts?  Seems to me like we should just fix the window.open feature
> > stuff to work right here.
> 
> I agree, that's a bug we should fix and it would fix this bug as filed.

You could fix the window.open feature. But that doesn't really address the core concern I have.
My main intent for this bug if a fundamental disagreement with reporting screen dimensions that also includes zoom. ATM, I'd favor zoom be the one property introduced separately.

> It might also make sense to introduce a standardized property that lets
> authors decompose devicePixelRatio into user zoom and screen DPI, i.e.
> expose one of user zoom or screen DPI explicitly, but that's really a
> standards issue and should be decided in www-style.

I have been meaning start a discussion on this myself. As I have done extensive research on this, for a complete script that detect all sort of cross platform contexts. So I have good knowledge about the differences between browsers in this matter.

Is is really a www-style matter ? Or web-app territory? I'd like to try and start a thread.

Comment 11

[Vlad Bacia-Mociran [:VladB]]

Hi,

After further investigations and thanks to new comments, I've understood the issue and indeed it's reproducible. 
What concerns me, is that screen proprieties are wrongly changing also on Windows 10 and Ubuntu 10.4.

Regarding this, I will change the Status to NEW.

Thank you,
Vlad

Comment 12

[progscrt]

Related issue

https://bugzilla.mozilla.org/show_bug.cgi?id=1292571

Comment 14

[numbermaniac]

The issue can also be reproduced on this website, without needing to reload the page each time: https://www.whatismybrowser.com/detect/how-big-is-my-web-browser.

The size shown doesn't change in Safari on macOS when zooming in or out, but it does change when zooming in or out in Firefox.

Comment 15

[Marouane]

Hello, Any update on this ?
The screen size is still related to the zoom ratio: http://www.whatismyscreenresolution.com