Closed Bug 547469 Opened 12 years ago Closed 7 years ago
.screen .width of the document returns css pixels corresponding to the full zoom level of the document .
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:220.127.116.11pre) Gecko/20100218 Firefox/3.6.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:18.104.22.168pre) Gecko/20100218 Namoroka/3.6.2pre ID:20100218052130 window.screen.width . window.screen.height . window.screen.availWidth . window.screen.availheight of the document returns css pixels corresponding to the full zoom level of the document. The other hand, Firefox3.0.x, Firefox3.5.x , Google Chrome22.214.171.124, Safari 4.0.4 and Opera10.10 return physical pixels size of monitor. Is this behavior intentional ? I could not find any specification revised about screen object in https://developer.mozilla.org/en/Firefox_3.6_for_developers . Reproducible: Always Steps to Reproduce: 1.Start Firefox with new profile 2.Open testcase 3.Full zoom Ctrl++ Ctrl++ Ctrl++ 4.Reload the testcase Actual Results: window.screen.width is physical pixels size of monitor. (returns 960 in 1280x1024 monitor and 133%full zoom ) Expected Results: window.screen.width is css pixels. (returns 1280 in 1280x1024 monitor and any full zoom level) Rgression window in 1.9.2: Works: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/589ffb95f90a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a2pre) Gecko/20090908 Namoroka/3.6a2pre ID:20090908044437 Broken: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4d62b8e4997a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a2pre) Gecko/20090909 Namoroka/3.6a2pre ID:20090909145110 Pushlog: http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=589ffb95f90a&tochange=4d62b8e4997a Rgression window in 1.9.3: Works: http://hg.mozilla.org/mozilla-central/rev/e3e594837a30 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090901 Minefield/3.7a1pre ID:20090901044858 Broken: http://hg.mozilla.org/mozilla-central/rev/75af94f85a98 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090902 Minefield/3.7a1pre ID:20090902045545 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e3e594837a30&tochange=75af94f85a98 Candidate regresssion: Bug 445765 - window.screen sometimes maps to wrong screen in multiple monitor environment
Sorry I miss take Actual Results: window.screen.width is "css pixels" (returns 960 in 1280x1024 monitor and 133%full zoom ) Expected Results: window.screen.width is "physical pixels size of monitor". (returns 1280 in 1280x1024 monitor and any full zoom level)
Assignee: nobody → tnikkel
Is this important enough to be needed on 1.9.2?
OS: Windows 7 → All
Hardware: x86 → All
So wait a sec. This code used to convert app units to css pixels all along, right. Did we just change what GetRect() on a device context returns? I think we really do want to be returning the size of the screen in CSS px, not device px; the only question is how it should interact with zoom.
We changed which device context window.screen uses to get its information. We used to always use one that didn't have zooming.
Ah. Well, in that case the patch changes behavior not back to what we used to have but to a different one, no? Is the new behavior really what we want?
I really do think we should return the screen size in CSS pixels. Can someone explain why they think we shouldn't?
CSS pixels based on the zoom of the current document? Or CSS pixels based on zoom=1? In the former case it would break with what we did before and apparently everyone else.
If specifications are not established in W3C etc., the return value should make much of compatibility with the other browser including 3.0 and 3.5.
(In reply to comment #10) > CSS pixels based on the zoom of the current document? Or CSS pixels based on > zoom=1? The current document. I agree that's different from what we used to do. But what exactly are people doing with the screen dimensions? If you want to do something like resize or move the window, which also takes CSS coordinates, surely you want to make screen dimensions use CSS.
If 1280x1024 monitor and full zoom 200%,http://uk.mail.yahoo.com/ does not work in Firefox3.6. I can not view the page with 200% full zoom. An error message as follows; ------------------ There seems to be a screen resolution problem. Your screen resolution is set below our minimum recommendation. When it's set under 1024 x 768 pixels, the all-new Yahoo! Mail won't look as good. ------------------- In Firefox3.5, I can do that.
The thing is, running at 200% zoom at 1280x1024 looks _exactly_ like running at 100% zoom at 640x512, doesn't it? In terms of what you can fit on the page, etc. So yes, it might not look as good! The fact that Yahoo then won't let you use their page is a Yahoo problem, though, and you would get exactly the same problem if you were actually using a low-res display instead of just emulating one.
(In reply to comment #14) > The thing is, running at 200% zoom at 1280x1024 looks _exactly_ like running at > 100% zoom at 640x512, doesn't it? In terms of what you can fit on the page, > etc. > > So yes, it might not look as good! The fact that Yahoo then won't let you use > their page is a Yahoo problem, though, and you would get exactly the same > problem if you were actually using a low-res display instead of just emulating > one. No.this is not site issue. because, no problem with Google chrome, Firefox3.5.8 and Firefox3.0.18. I did not try with ie8 and safari yet. Not working with Firefox 3.6.2pre and Minefield3.7a2pre only. This is browser compatibility issue. Not the site issue.
It's a site issue if the site refuses to be viewed at certain screen resolutions, period. Your claim is that claiming a difference in the screen resolution is a web browser bug. But roc's point is that zooming has _exactly_ the same effect as changing the screen resolution. We used to treat them differently in terms of reporting screen sizes, but now we treat them the same, because the _are_ the same in their effects. The fact that no other browser does that doesn't necessarily make it wrong.
Are there documentations and/or existing problems to change the specifications of the screen object?
I'm pretty sure it's not specified exactly what units the screen object's properties should use. I don't think it would make sense to specify that the pixels used by screen.width and screen.height should be different from the size of a CSS "px". I think letting the pixels used by screen.width and screen.height be different from a CSS "px" was a bug in Firefox (and is still a bug in Chrome). I think complaining about the user's screen size is a bug in Yahoo Mail.
Fix regression first of all. We should argue about the specifications separately.
Sites often depend on browser bugs. Sometimes when we fix bugs, those sites stop working, but we often try to get sites to fix their behaviour instead of re-adding our bug. This is how we make progress on the Web.
Assignee: tnikkel → english-other
Component: Layout → English Other
Product: Core → Tech Evangelism
QA Contact: layout → english-other
Version: 1.9.2 Branch → unspecified
If this change is by design (I don't think so), could someone mention that on the related MDC documents? https://developer.mozilla.org/en/Firefox_3.6_for_developers https://developer.mozilla.org/en/DOM/window.screen.width https://developer.mozilla.org/en/DOM/window.screen.height https://developer.mozilla.org/en/DOM/window.resizeTo https://developer.mozilla.org/en/DOM/window.resizeBy
This *bug* affects our Foxkeh's Wallpaper Creator http://wallpapers.foxkeh.com/en/ as mentioned in the FAQ: http://wallpapers.foxkeh.com/en/faq.html If users zoom the content, the screen size cannot be detected. No workarounds available here. Very annoying regression for Web developers :(
> If users zoom the content, the screen size cannot be detected. Which screen size? Screen size in the px units the web page sees can be detected. Screen size in the units the OS sees cannot, but that's none of the web page's business.
(In reply to comment #20) > Sites often depend on browser bugs. Sometimes when we fix bugs, those sites > stop working, but we often try to get sites to fix their behaviour instead of > re-adding our bug. This is how we make progress on the Web. This new behavior is side effect by Bug 445765 fix, isn't it? Nobody discuss about the specifications of the screen object. And who decided this behavior? we differ from our former behavior and another browser's behavior. Where are "TE" grounds? Any Specification? Any notes?
(In reply to comment #25) > (In reply to comment #20) > > Sites often depend on browser bugs. Sometimes when we fix bugs, those sites > > stop working, but we often try to get sites to fix their behaviour instead > > of re-adding our bug. This is how we make progress on the Web. > > This new behavior is side effect by Bug 445765 fix, isn't it? No, bug 445765 should not have affected this. > Nobody discuss about the specifications of the screen object. > And who decided this behavior? I'll take responsibility for that. > we differ from our former behavior and another browser's behavior. Yes. Previous browser behaviors made no sense. Providing values in "OS screen pixels" is not useful since that unit is meaningless for Web pages. A Web page can't size anything or position anything in OS screen pixels, only CSS pixels. > Where are "TE" grounds? Any Specification? Any notes? I will try to get this change added to http://dev.w3.org/csswg/cssom-view/#the-screen-interface. Thanks for reminding me about this.
Actually, rereading the CSSOM View spec, it already says that our behavior is correct: > All coordinates and dimensions for the APIs defined in this specification are > in CSS pixels. So that is the reference we can use for TE.
(In reply to comment #23) > This *bug* affects our Foxkeh's Wallpaper Creator > http://wallpapers.foxkeh.com/en/ > as mentioned in the FAQ: > http://wallpapers.foxkeh.com/en/faq.html > > If users zoom the content, the screen size cannot be detected. > > No workarounds available here. Very annoying regression for Web developers :( Foxkeh is a special case because it is outputting graphics that are to be used as a desktop image. Web apps that create graphics to fit the screen *outside the browser* need a new API. The -moz-device-pixel-ratio CSS media query would help with that.
Depends on: 474356
This intends to make popup of size(W=100% , H=50%)of screen. on Firefox3.5.x, Size of popup window does not affect the full zoom level of opener. on Firefox3.6.x or later, if opener document was full zoom-in/out, the popup is smaller/larger than intended size. I think this is a problem. How do you control this popup size?
(In reply to comment #29) Sorry, my English. >on Firefox3.5.x, >Size of popup window does not affect the full zoom level of opener. on Firefox3.5.x, The full zoom level of opener does not affect size of popup window
That sounds like a separate bug. Our code is definitely *trying* to interpret window.open width/height as CSS pixels: http://mxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#1980
Should probably have a bug on actually interpreting those values in CSS pixels of the window that called window.open, not CSS pixels of the root chrome widget.
Yes, it's a bug. We're computing the wrong devPixelsPerCSSPixel. This may have actually regressed after bug 130078.
(In reply to comment #32) > Should probably have a bug on actually interpreting those values in CSS pixels > of the window that called window.open, not CSS pixels of the root chrome > widget. Indeed!
Filed bug 594140 on that.
I don't think 130078 changed anything here. The docshell hierarchy was unchanged with bug 130078, so I think the docshell tree owner would be the same before and after 130078.
At Vimeo we use screen.width and screen.height to help us determine what kind of device the user is on so we can load the appropriate player. Zooming in really screws this up for us. I can understand window.innerWidth/Height returning the values in CSS pixels, but what about when you need to know the actual resolution of a device? Now in Firefox only, we're SOL.
Why does the player to load depend on the physical device resolution, exactly?
Ideally, we would also take into account the physical size as well, but there's no API for that. Depending on the size of the device, we need to show differently-sized controls to make it easier to use. The complexity of them makes it so we can't just scale them up and down. Basically, we tried a bunch of things and using screen resolution was the best option. It would be nicer for developers if the current implementation matches previous Firefox implementations and the implementations of other browsers.
> Depending on the size of the device, we need to show differently-sized controls to make > it easier to use. Hmm. So are you basically aiming for a fixed physical size for the controls (e.g. for touch controls), but have to deal with your preferred physical size not fitting on some devices? Seems like if so you could measure how many CSS px a mozmm (physical mm) is, if that's the information you're really after. I agree that it would be good to have cross-browser way to do this; we made some proposals at one point but they seem to have gone nowhere....
You can estimate the screen size in device pixels using media queries on -moz-device-pixel-ratio combined with screenX/Y.
Robert, why is this a Tech Evangelism bug? And what are the concrete actions expected with regards to this bug? Any precise person/site to contact?
Assignee: english-other → nobody
Component: English Other → Desktop
had forgotten the needinfo see Comment #44
I had assumed Alice had found a bug using an existing site, but I see she didn't mention it here, so there's no actionable information in this bug.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.