Last Comment Bug 674292 - Drop support for UIEvent.layerX and UIEvent.layerY
: Drop support for UIEvent.layerX and UIEvent.layerY
Status: UNCONFIRMED
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: unspecified
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 69787
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-26 11:17 PDT by Julien Chaffraix
Modified: 2015-05-18 08:55 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Julien Chaffraix 2011-07-26 11:17:49 PDT
Per discussion on #content, this is a request to drop support for MouseEvent's layerX and layerY. It is currently supported only by Gecko and WebKit (context for WebKit -> https://bugs.webkit.org/show_bug.cgi?id=21868).

WebKit is considering removing those 2 properties as our code looks extremely old and we had zero bug about that.
Comment 1 Olli Pettay [:smaug] (reviewing overload) 2011-07-26 11:23:27 PDT
http://www.google.com/codesearch#search/&q=layerX%20lang:%5Ejavascript$&p=4&sq=&type=cs
gives quite a few results.

But still layerX/Y aren't probably used too often, alhtough they can be useful
when handling positioned elements.

Jonas, Boris, Roc, any comments?
Comment 2 Olli Pettay [:smaug] (reviewing overload) 2011-07-26 11:29:47 PDT
Also, getting coordinates relative to the top-left corner of scrollable
element can be quite useful.
Comment 3 Olli Pettay [:smaug] (reviewing overload) 2011-07-26 12:04:16 PDT
Simon, you suggested dropping layerX/Y. 
May I ask why? Just because they are rarely used, or do you see
something badly wrong with them?
Comment 4 Simon Fraser 2011-07-31 13:26:35 PDT
They are not specified anywhere, the 'layer' name seems to be a holdover from Netscape 4 "layers", and WebKit's implementation was very probably wrong.
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-01 01:01:34 PDT
I think we should try removing them.
Comment 6 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-08-01 10:06:22 PDT
I agree, we should try to remove this. We absolutely do need an API for dealing with coordinates when there are scrollable and transformed regions involved, but layerX and layerY are unlikely to cut it. I'd be much more interested to see a function which let you pass in an element and returned the event's coordinates in that element's coordinate space.

Maybe a good approach here is to add warnings on trunk right now, and remove the functions completely in a couple of weeks when we've branched for FF8.
Comment 7 Julien Chaffraix 2011-10-13 17:57:49 PDT
FYI, as of today, WebKit has deprecated layerX / layerY (we show a warning in the console when they are used). Due to them being exposed in one native API, they will survive until removed from there.
Comment 8 Masatoshi Kimura [:emk] 2011-10-26 00:28:15 PDT
We should add support for offsetX/offsetY which is defined in CSSOM View before dropping layerX/layerY.
http://www.w3.org/TR/cssom-view/#dom-mouseevent-offsetx
Comment 9 Olli Pettay [:smaug] (reviewing overload) 2011-10-26 04:32:51 PDT
offsetX/Y is a different beast. What have they to do with layerX/Y?
Comment 10 Masatoshi Kimura [:emk] 2011-10-26 04:56:22 PDT
layerX/Y is often used to compensate a lacking support for offsetX/offsetY.
Comment 11 henryfhchan 2012-01-26 06:15:04 PST
http://msdn.microsoft.com/en-us/library/ms530302%28VS.85%29.aspx

IE now uses layerX layerY for calculating offset to parent's border, not affected by transform.

keep the compatibility?
Comment 12 Flame 2012-03-06 11:40:20 PST
There is no valid justification for removing layerX/Y.

layerX/Y are supported in Firefox, Chrome & IE. They work exactly as expected and as documented. 

Why would you remove useful perfectly working cross-browser compatible functionality with no equivalent functionality to replace it?

I use layerX/Y extensively and have done so for many years, I'm sure that I can't be the only person who will be caused massive problems by the removal of these properties.
Comment 13 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-03-06 11:49:47 PST
layerX/Y work in IE?  That's not what comment 0 says ...
Comment 14 Nathan Froyd [:froydnj] 2012-03-06 12:11:54 PST
Comment 11 suggests that IE does (recent versions only?) and so do pages like http://msdn.microsoft.com/en-us/library/gg130967%28v=vs.85%29.aspx  That page explicitly indicates it is for cross-browser compatibility.
Comment 15 Flame 2012-03-06 12:27:13 PST
I don't know which version of IE supports the properties as layerX/Y (IE8 does not) but they are just an alias for the x/y properties which have been in IE for years and have the same functionality as layerX/Y.

see
http://msdn.microsoft.com/en-us/library/ff974658(v=vs.85).aspx
Comment 16 Joel Stevenson 2015-01-16 18:25:50 PST
FWIW Firefox's layerX/Y differs in implementation from Chrome, Safari, and IE now, with regard to some transformed elements.  I haven't done extensive testing but on an element that has the following example transform:

-moz-transform: matrix3d(2.20842572062084, 0, 0, 0.00241685144124169, 0, 2.11751662971175, 0, 0.00372505543237251, 0, 0, 1, 0, 0, 0, 0, 1);
-moz-transform-origin: 0px 0px 0px;

Chrome, Safari, and IE report layerX/Y values for the element's original bounding box and FF reports layerX/Y more inline with what the offetX/Y would be (if FF implemented those) - which is to say where the location is as if it had happened on the untransformed element.

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