Exposing content area coordinates

[michaelwasserman]

Currently, the window object exposes:

• screenX and screenY: the x/y-coordinate, relative to the origin of the screen of the output device, of the left/top of the client window as number of pixels.
• innerWidth and innerHeight: the viewport width/height including the size of a rendered scroll bar (if any).
• outerWidth and outerHeight: the width/height of the client window.

It's not currently possible to determine the x/y coordinates of the content viewport relative to the screen of the output device (see also w3c/csswg-drafts#809). Some window placement use cases would benefit from this information (e.g. opening a popup aligned with content in the opener, aligning content with the edge of a screen when the document spans multiple screens). It may be reasonable to extend the window interface with such attributes, e.g.:

• innerScreenX and innerScreenY: the number of CSS pixels from the left/top edge of the content viewport to the left/top edge of the screen. (alternate names: viewportX|Y, innerX|Y, with Left and Top aliases as desired) Alternatively, these could be exposed as offsets of the content viewport relative to the client window.

Aside: In some implementations, screenX and screenY may incorrectly reflect the placement of the content viewport, instead of reflecting the placement of the client window, or be altogether buggy; e.g. http://crbug.com/1286870

[quisquous]

The last sentence is intended to be http://crbug.com/1286870, I think?

[michaelwasserman]

Yes, updated, thanks!

[el-dav]

This feature would be essential for my use case which is building a multi-window drag-and-drop system.

I was intending to do this using a global co-ordinate system so the various windows know their relative position, whether they are docked iframes or separate windows. But it's currently not possible without the viewport coordinates relative to the screen.

[jpw-1975]

My use-case is exactly the same. We've been using drag and drop events to accomplish this so far, which works well, but prevents us from customizing the mouse cursor, which is important for our use-case. Using screen coordinates kind-of works, but we need to know both the viewport offset and the browser zoom level. The latter is not mentioned in this bug, but IMO needs to be a part of this for the use-cases described.

[iamherrylok]

there is great need for expose it! It's difficult to get the elemnt coordinate relative to screen when download bar appears!

[michaelwasserman]

An old Chromium issue to support mozInnerScreenX|Y also cited a gaze tracking use case.