Open Bug 1292571 Opened 9 years ago Updated 5 months ago

Wrong Real Screen Size while zoom

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Version:
48 Branch
Type:
defect

Tracking

()

People

(Reporter: progscrt, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Steps to reproduce: 1. Open any website in FireFox, PC windows/linux version 2. Open WebConsole, call >screen.width to see screen width 3. Increase zoom by CTRL++ (or choose from menu). For example, lets 150% 4. Repeat >screen.width in WebConsole to see screen width again Actual results: In my case, real display resolution is 1600x900 So, first time, value screen.width = 1600 (zoom 100%) second time, after zoom becomes 150%, screen.width = 1067 Expected results: screen.width and screen.height must be independent from zoom. In my case, for: - zoom 100%, screen.width must equals 1600 - zoom 150%, screen.width must equals 1600 This issue found in FireFox PC version, mobile versions works well. Also, tested on Firefox mobile versions (IOS) - works as expected, screen.width always 1600 Safari, Chrome, Opera (mobile and PC versions) - works as expected
Correction, I want write on iOS screen width always same, independent from zoom factor.
This is reproducible in windows and Ubuntu with latest nightly and release versions. --- Version 51.0a1 Build ID 20160810030202 Update Channel nightly User Agent Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Status: UNCONFIRMED → NEW
Component: Untriaged → Panning and Zooming
Ever confirmed: true
Product: Firefox → Core
I believe Firefox's behaviour here is correct. The CSS spec defines screen.width as returning "the width of the output device, in CSS pixels" [1]. When you change the browser zoom, the width of the output device changes in CSS pixel terms, so the value reported by screen.width changes accordingly. [1] https://drafts.csswg.org/cssom-view/#dom-screen-width
(In reply to Botond Ballo [:botond] from comment #3) > I believe Firefox's behaviour here is correct. The CSS spec defines > screen.width as returning "the width of the output device, in CSS pixels" > [1]. When you change the browser zoom, the width of the output device > changes in CSS pixel terms, so the value reported by screen.width changes > accordingly. > > [1] https://drafts.csswg.org/cssom-view/#dom-screen-width Let myself suggest that the mobile version in that case does not work properly, am I right? As I wrote above, mobile version screen.width don't changes while I play with zoom. FireFox mobile and desktop versions has different behaviour of screen.width - it is fact. I read W3C draft and I wonder, only FireFox (desktop version) interpret CSS pixels this way. I checked: Chrome, Opera, FireFox, Safari, IE 11, Android default browser, mobile and desktop versions - all they use real pixels for screen.width Please check twice, coz, this is big problem for some developers.
(In reply to progscrt from comment #4) > (In reply to Botond Ballo [:botond] from comment #3) > > I believe Firefox's behaviour here is correct. The CSS spec defines > > screen.width as returning "the width of the output device, in CSS pixels" > > [1]. When you change the browser zoom, the width of the output device > > changes in CSS pixel terms, so the value reported by screen.width changes > > accordingly. > > > > [1] https://drafts.csswg.org/cssom-view/#dom-screen-width > > Let myself suggest that the mobile version in that case does not work > properly, am I right? I just tested Firefox for Android, and you're right, zooming in does not affect the value of screen.width there. If my interpretation of the spec is correct, then this is a bug, yes. Firefox for iOS uses WebKit as its rendering engine (because that's the only thing Apple allows on its platform), so it will inherit whatever behaviour WebKit has. > I read W3C draft and I wonder, only FireFox (desktop version) interpret CSS > pixels this way. > > I checked: Chrome, Opera, FireFox, Safari, IE 11, Android default browser, > mobile and desktop versions - all they use real pixels for screen.width > > Please check twice, coz, this is big problem for some developers. According to my testing, IE 11 and Edge share Firefox's behaviour. That said, there is enough implementation divergence here that it's worth raising a spec issue to clarify the situation.
(In reply to Botond Ballo [:botond] from comment #5) > That said, there is enough implementation divergence here that it's worth > raising a spec issue to clarify the situation. I filed a spec issue here [1]. Let's see what other implementers have to say. [1] https://github.com/w3c/csswg-drafts/issues/399
Oh, sorry, IE share behaviour with FireFox desktop v. I use (screen.width / window.innerWidth) to get zoom factor. But for IE, screen.deviceXDPI / screen.logicalXDPI I have not found simple solution to obtain zoom factor in FireFox desktop version. Thank you, let's see what other implementations...
(In reply to progscrt from comment #7) > I have not found simple solution to obtain zoom factor in FireFox desktop > version. Does window.devicePixelRatio [1] work? [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio
I made small test for devicePixelRatio and result not stable. For example, FireFox and Chrome desktop versions devicePixelRatio result depend on zoom, it can be 0.5 for 50% and 1.5 for 150% - looks good. FireFox and Chrome, Safari, Opera mobile versions devicePixelRatio result always 2, for any zoom level.
(In reply to progscrt from comment #9) > I made small test for devicePixelRatio and result not stable. > > For example, > FireFox and Chrome desktop versions devicePixelRatio result depend on zoom, > it can be 0.5 for 50% and 1.5 for 150% - looks good. > > FireFox and Chrome, Safari, Opera mobile versions devicePixelRatio result > always 2, for any zoom level. The reason is that there are several factors that go into the ratio between CSS pixels and pixels on the screen: (A) The system device pixel ratio. This is a value that depends on the device that's always factored in. Its purpose is to make sure that pages aren't unreadably small on higher-density screens. (B) The reflowing zoom, also known as "full zoom". The increases the size of the page contents while keeping the viewport width fixed. When this changes, the page is reflowed so the contents still fit into the viewport width (e.g. a paragraph of text may take up more lines as a result). This is only supported on desktop browsers. (C) The non-reflowing zoom, also known as "pinch zoom". Typically activated by making a pinch gesture or double-tapping. This increases the size of the page contents and the size of the page's viewport simultaneously, so nothing is reflowed, you're literally just zooming in on a rectangle of the page. This is only supported on mobile browsers. window.devicePixelRatio basically returns A * B. The reason you're seeing it be 2 on your mobile device is that your device has an A value of 2. C isn't exposed directly, but it can be calculated as document.documentElement.clientWidth / window.innerWidth. Hope that helps!
My task is make DIV element with static size (zoom independent) So, I calculate zoom factor each time onresize/onorientationchange/ontouchmove events and change DIV height and width. Unfortunately, I can't found universal way to calculate zoom in FF desktop version. I can use devicePixelRatio, but I don't want to add extra JS code to detect browser is FireFox and version is desktop. Also, if this behaviour correct, and Chrome, Safari, Opera will change it in the future, where is no easy universal way to get zoom factor?
Zoom can be obtain with CSS mediaQuery. Sample here https://jsfiddle.net/5gzommjh/3/ But don't want use this heavy solution for simple zoom factor
Whiteboard: [gfx-noted]
I'd like to be able to tell you that there's a simple API that works across all browsers and form factors, but I don't know of one. (I'll also note that there's a user choice vs. developer choice tradeoff in exposing such an API. Users often use zoom to make small text more readable or see an image in more detail. The level of zoom for comfortable viewing varies from user to user. As a developer, by making an element unzoomable (by resizing it to retain its original size when the user zooms in), you are taking away the user's choice to view that element at a larger resolution. It's not clear to me that being able to do this is desirable.)
I understand user experience and make unzoomable with careful.
P3 while we wait for clarification on the spec issue.
Priority: -- → P3
20 days - no one comment on spec issue. Is it normal practics?
It's not uncommon, unfortunately.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.