Bug 12753 – Incorrect values for window.screenTop and window.screenLeft

• Component: DOM
• Status: RESOLVED WONTFIX

[Tom Brown]

In javascript, the screenX and screenY members of the window object give the screen coordinates of the top-left coordinates of the chrome window. This is incorrect. The values returned should point to the first pixel in the content window.

Firefox returns the first pixel of the content window as (window.screenX, window.screenY). IE returns the first pixel of the content window as (window.screenTop,window.screenLeft).

This is happening because the outer window rectangle is used as the return value for these properties: kjs_window.cpp:

case ScreenTop:
case ScreenY:
  return jsNumber(m_frame->page()->chrome()->windowRect().y());

[Tom Brown]

Created attachment 13146 [details]
Demonstration script/Test reduction

1) Open the repduction.
2) Move the mouse to the top of the document.
3) Observe that "Adjusted Y" does not approach zero at the top of the document.

[Tom Brown]

Update: The screenX and screenY members provide the correct values. However, screenLeft and screenTop should return different values. The screenX and screenY properties used by mozilla refer to the screen coordinates of the top-left pixel of the chrome window.

However, the screenLeft and screenTop members of the IE window object refer to the  screen coordinates of the top-left pixel of the current document.

[Marcus Better]

This is a case where WebKit implements an IE-specific property but in an incompatible manner. This is IMHO worse than not having screenLeft/Top at all.

[Dimitri Allegoet]

Greetings everyone,

The malfunctioning of screenLeft and screenTop has another dramatic effect. 
When in an Iframe, these coordinates are completely off, especially with scrolling.

I believe the expected behavior in this case is to return the screen coordinates of the top-left pixel of the current document, i.e. the iframe one.

In the kjs_window.cpp file, isn’t the fix as simple as: 
case ScreenTop:
        if (!isSafeScript(exec)) 
            return jsUndefined();
      return jsNumber(m_frame->view()->windowRect().y());

This works perfectly well under IE and Firefox (Firefox has its own set of property names; I can retrieve them if you like).
It would be great if this can be fixed as it prevents our client’s widgets to work correctly under Chrome/Safari :(

[Gérard Talbot (no longer involved)]

Documentation
-------------

window.screenX (part of CSSOM View Module)
https://www.w3.org/TR/cssom-view-1/#dom-window-screenx
https://drafts.csswg.org/cssom-view/#dom-window-screenx
and
https://developer.mozilla.org/en/docs/Web/API/Window/screenX


window.mozInnerScreenX
https://developer.mozilla.org/en-US/docs/Web/API/Window/mozInnerScreenX


window.screenY (part of CSSOM View Module)
https://www.w3.org/TR/cssom-view-1/#dom-window-screeny
https://drafts.csswg.org/cssom-view/#dom-window-screeny
and
https://developer.mozilla.org/en/docs/Web/API/Window/screenY


window.mozInnerScreenY
https://developer.mozilla.org/en-US/docs/Web/API/Window/mozInnerScreenY


window.screenLeft (part of IE proprietary DOM0 model)
"Retrieves the x-coordinate of the upper left-hand corner of the window 
frame, relative to the upper left-hand corner of the screen."
https://msdn.microsoft.com/en-us/library/ms534389(v=vs.85).aspx


window.screenTop (part of IE proprietary DOM0 model)
"Retrieves the y-coordinate of the top corner of the client area, relative to the top corner of the screen."
https://msdn.microsoft.com/en-us/library/ms534390(v=vs.85).aspx


Interactive DHTML demo
----------------------

http://www.gtalbot.org/DHTMLSection/WindowEventsNS6.html

the screenX, mozInnerScreenX, screenY, mozInnerScreenY values are inside the "Screen and window data" layer which can be resized. Moving the window, adding or removing various toolbars (or sidebar or explorer bar) will impact those window properties values.


Screenshots
-----------

What those window.screenX, window.screenLeft, window.screenY and window.screenTop properties refer to in browsers:

http://www.gtalbot.org/DHTMLSection/ScreenXYComparedScreenLeftTop.html


Useful links
------------

Re: window.innerScreenX and window.innerScreenY
http://lists.w3.org/Archives/Public/www-style/2016Dec/0054.html


Webkit equivalents of mozInnerScreenX / Y
https://bugs.chromium.org/p/chromium/issues/detail?id=151983


Bug 486200: Need API to compute screen coordinates of DOM elements
https://bugzilla.mozilla.org/show_bug.cgi?id=486200#c1
"
(...) to add window.mozInnerScreenX/Y properties that return 
the screen coordinates of the top-left of the viewport. It should be 
trivial, I'll do it ASAP.
"

[Gérard Talbot (no longer involved)]

I think Component for this bug should be "HTML DOM" since this is a DOM0 related issue and not a js engine issue.

[Simon Fraser (smfr)]

Isn't there talk of not allowing JS to know where the window is on screen, for privacy reasons?

[Gérard Talbot (no longer involved)]

> Isn't there talk of not allowing JS to know where the window is on 
> screen, for privacy reasons?

I do not know of this or about this. I have not heard of this or about this before.

- - - - - - 

https://bugs.chromium.org/p/chromium/issues/detail?id=151983#c9

[Matryoshka] - Wrapping Overflow Leak on Frames
http://sirdarckcat.blogspot.ca/2013/09/matryoshka-wrapping-overflow-leak-on.html

I am not sure I understand why knowing where the position of the iframe relative to the browser and screen can become a security/privacy issue. By itself alone, I do not see how this can represent a security concern ... but maybe in conjunction with other tricks and hacks... I really do not know.

- - - - - - - 

If a javascript can figure out the window frame border thickness, the window.outerHeight, the window.innerHeight and if there is an horizontal scrollbar and/or vertical scrollbar, if a window is maximized, etc..., then it is often possible to know the x,y coordinates of the top-left corner of the client area, even in webkit browsers. It's just a matter of calculations of already available window and screen data and logical deductions.

[Anne van Kesteren]

As Simon says we want to eventually always return 0 or some such for these to prevent fingerprinting. Having these be accurate is a non-goal.