Closed Bug 547469 Opened 14 years ago Closed 10 years ago

window.screen.width of the document returns css pixels corresponding to the full zoom level of the document.

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: dev-doc-needed, regression, Whiteboard: [css])

Attachments

(3 files)

testcase
621 bytes, text/html
Details
patch
2.16 KB, patch
Details | Diff | Splinter Review
testcase
460 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100218 Firefox/3.6.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) 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 Chrome4.0.249.89, 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
Blocks: 445765
Keywords: regression
Attached file testcase — 

    
  
Version: unspecified → 1.9.2 Branch

    
    

    
  
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
Assignee: nobody → tnikkel

        Attachment #428014 -
        Flags: review?(dbaron)

    
    

    
  
Is this important enough to be needed on 1.9.2?

    
    

    
  
This is a major regression breaking website compatibility and should be fixed on 1.9.2.2.

You can test this with a simple JavaScript snippet (or bookmarklet):
javascript:window.resizeTo(1024,768)
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.

        Attachment #428014 -
        Flags: review?(dbaron)

    
    

    
  
(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

    
    

    
  
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

    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  
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!

    
    

    
  
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.

    
    

    
  
Whatever the outcome of the discussion whether window.screen.width outputs CSS pixels or device pixels — I think and strongly advocate the notion that Firefox /should/ provide a means to query the CSS pixels at 100% full page zoom level, so that the value corresponds to the actual screen resolution. 

For example, my resolution is 1680x1050 and some javascript function, say window.screen.pixelsX, should output the value of 1680 regardless of the page being zoomed in or out.

If I as a website author decide that I want a page to occupy 60% of the screen width [1] (20% blank space each, left and right) for a default zoom level of 100%, but enable the – say, visually impaired user – to zoom the whole page in to get that page occupy 100% of the available screen width (no 'wasted' blank space on the sides, then, of course), I cannot reliably do this, when I cannot relate to a _fixed_ px width that accounts for 100% of the screen width.

Because if I set the page width to 60 'CSS-%', zooming in only zooms the content of the page with the page still occupying 60% of the available width (still with blank 20% space on each sides), which makes the content hard to read (few words per line in each column).

Of course, I could fix these 60% page width to some arbitrary pixel value, but which should one should I use? 0.6*1280? 0.6*1600? 0.6*1920?

I kindly ask you to implement some function like the one outlined above or at least some means to query the zoom level so the device resolution can be calculated.

Thank you very much!



  [1] Which I do by passing the screen width as a variable to php which creates the style sheet 'on the fly' with the calculated pixel values.

    
    

    
  
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
Whiteboard: [css]

    
    

    
  
had forgotten the needinfo see Comment #44
Flags: needinfo?(roc)

    
    

    
  
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: 10 years ago
Flags: needinfo?(roc)
Resolution: --- → INCOMPLETE
Product: Tech Evangelism → Web Compatibility

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: