W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2015

[Bug 28029] New: Mouse coordinates represented in CSS pixels do not account for retina displays with window.devicePixelRatio > 1.

From: <bugzilla@jessica.w3.org>
Date: Sat, 14 Feb 2015 18:52:55 +0000
To: www-dom@w3.org
Message-ID: <bug-28029-4009@http.www.w3.org/Bugs/Public/>

            Bug ID: 28029
           Summary: Mouse coordinates represented in CSS pixels do not
                    account for retina displays with
                    window.devicePixelRatio > 1.
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM3 Events
          Assignee: travil@microsoft.com
          Reporter: jujjyl@gmail.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

In e.g. the MouseEvent structure, the mouse xy coordinates are stored with the
data type 'long', see here:
http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent .

There does not seem to be a clear documentation on how these coordinates relate
to the value of window.devicePixelRatio (or I'm missing it). Looking at current
implementation in Firefox, Safari and Chrome, the coordinate system that the
fields clientX, clientY, screenX and screenY are specified in are the
hardware-independent "CSS pixel" units meaning that they do not directly
correspond to physical pixels on the display.

That is, testing on a Macbook Pro with 2880x1800 retina display, in each
Firefox, Chrome and Safari, window.devicePixelRatio gives 2, and running this


the extents of screenX and screenY range between (0, 0) and (1440, 900). In
order to get the exact pixel coordinate where the mouse lies in, one must
multiply the screenX and screenY parameters by window.devicePixelRatio, i.e. by
a factor of 2 in this case.

However, since screenX and screenY (and all the other fields that represent
mouse coordinates are of type 'long', this means that after multiplying, in
both X and Y directions every second pixel is missed and only 25% of all pixels
on the display are addressable by screenX and screenY.

4K resolutions are coming in fast, and I expect that browsers might use a
window.devicePixelRatio of 4 on those displays. This would mean that only
1/16th or 6.25% of all hardware pixels would be addressable by the mouse event

It looks like all the mouse coordinates throughout all events in the DOM specs
should be passed as type 'double' instead of 'long' in places where the
coordinates are represented in CSS pixels so that each hardware pixel will be

I wonder if I'm missing something here, and if this issue can be (has been?)
resolved in some other way?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Saturday, 14 February 2015 18:52:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:23 UTC