69787 - Implement MSIE's event.offsetX, event.offsetY as mouse coordinates inside target element

Status: RESOLVED FIXED

(Core :: DOM: Events, enhancement, P4)

Description

[Chris Bodart]

The current DOM spec fails to suggest that Event Objects (specifically Mouse 
Events) should really support offsetLeft and top values relative to the 
parentNode with is positioned (offsetParent)

This of course is somewhat annoying as the events report only positioning 
relative to document and to screen (which ofcourse means that a lot of 
calculation is involved for any scripting purposes as any HTMLElement only 
gives away offsetValues NOT document/screen relative positioning values

This system is implemented in IE4+ (event.offsetLeft etc) and NS4 (event.layerX 
etc) and is more than slightly useful

No testcase need be given as this is purely a question of whether the specs 
need changing (and thus the browser too)

(PS an event.returnValue would also be most useful but I cant make a case for 
it beyond saying it would make my life as a Web Application Developer very 
easy!!)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Actually, mozilla implements offsetLeft, offsetTop, offsetParent, offsetWidth,
offsetHeight, etc for IE compatibility, precisely because the W3C DOM does not
define useful equivalents.

Marking duplicate of "RFE: No way to find size/position via DOM"

*** This bug has been marked as a duplicate of 9844 ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

Reopening.  offsetLeft and company are indeed not defined for mouse events.  My
apologies.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Simple testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

we now have some new DOM components...

Comment 5

[Johnny Stenback (:jst)]

Reassigning to joki and Futuring based on a discussion with him.

Comment 6

[Johnny Stenback (:jst)]

Really reassigning this time.

Comment 7

[Gérard Talbot]

offsetTop, offsetLeft, offsetParent, offsetWidth, etc... are DHTML object
properties which Mozilla and Firefox support, just like MSIE 5+. These are NOT
event properties. These are element properties.

OTOH, offsetX and offsetY are MSIE event properties and useful properties for,
say, easily and quickly determining mouse coordinates inside the target element:
 eg. mouse (x, y) coordinates in an <img> in a click event.

So saying
> This system is implemented in IE4+ (event.offsetLeft etc)
is not accurate.

http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MouseEvent

Also, this page is working for listing all event object properties for MSIE 6
and Mozilla:

http://www.gtalbot.org/HTMLJavascriptCSS/ListAllAttributesAndMethodsOfObjects.html

Resolving as INVALID

Comment 8

[Boris Zbarsky [:bzbarsky]]

Why is t his invalid?  We still don't provide an equivalent to offsetX/offsetY
on Gecko events.

It might be wontfix, but that's the module owner's call.

Comment 9

[Gérard Talbot]

> Why is t his invalid? 

The summary as written has a lot of inaccuracies. The description is incorrect
at several spots and does not clearly indicate what should be.

 We still don't provide an equivalent to offsetX/offsetY
> on Gecko events.

Mozilla-based browsers can provide the equivalent to MSIE's
evt.offsetX/evt.offsetY as explained in bug 122665 comment 3. It is not a
direct, immediate and straightforward equivalent though.
If Mozilla should provide an equivalent to offsetX/offsetY, then it should be
with the same name and same functioning/implementation as in MSIE. Already Opera
7+ has bugs with that implementation.

If dragging a DHTML layer is involved, then Mozilla already has
evt.layerX/evt.layerY which fits perfectly coding needs: see function Activate
of attachment 101322 [details] for an example

Sometimes web amateurs want to know where an event (like a click) occured inside
an image (or inside any non-absolutely-positioned element serving as the event
target) for various reasons. Then, MSIE's support for
event.offsetX/event.offsetY makes the task of web designers easier. No need for
cumulating offsetLeft/offsetTop values within the containment hierarchy and make
calculations.

> It might be wontfix, but that's the module owner's call.
Of course.

Re-summarizing

Comment 10

[carglue a t ya hoo do tcom]

There's more to this issue than what's been discussed.  Let me explain:
 
In the current version of firefox/mozilla, when an image input element on a 
form (method=post) is clicked, the resulting POST message string will be 
automatically appended with 2 additional name-value pairs giving the x,y 
offset coordinates that are relative to the clicked image as a set of 
additional name-value pairs on the end of the post string:
 
...&MyImageName.x=7&MyImageName.y=9
 
These extra post parameters let the server-side CGI scripts determine which 
image input element (out of a possible set on the page) was clicked. That is, 
the image name with non-zero x and y coords is the one that was clicked, all 
the others were not.  So far so good. The problem is, in Mozilla the behavior 
is different between interactive and synthetic event creation.  On a 
programmatically injected event, the x,y coords are always set to zero.  I've 
found no way to change this.
 
More Info...
Using an onSubmit event listener, I can see that when I click an image input 
element interactively, the event that is caught has an explicitOriginalTarget 
child node that points to the correct HTMLInputElement that I clicked on.  It 
shows the necessary image offset coordinates which are appended to the post 
string.  However, if I recreate the exact same event programmatically using 
initMouseEvent or initEvent, that same onSubmit handler will show the 
explicitOriginalTarget as an HTMLFormElement elment instead, resulting in lost 
image offset data.
 
Its not clear to me at the moment, but somehow it appears that the 
HTMLInputElement gets re-parented to an HTMLFormElement when an event is 
created programmatically, but not when its generated interactively. I've tried 
to explore many different paths to resolving the issue, such as resetting the 
explicitOriginalTarget value (can't, its read-only), researching the DOM3 
initUIEvent method (still not be implemented in mozilla??), and other stuff 
such as the possibility of mouse events and views. The only possible way I can 
see around this is a very ugly hack to use a regex on the actual post data 
stream to convert the .x=0 and .y=0 values to non-zero values.  This is a very 
nasty and impractical solution.
 
For these reasons, I would consider this to be a fairly serious issue that 
needs attention.  I would also be very interested to find out if there is a 
workaround (besides modifying the in-flight post stream).

Comment 11

[Boris Zbarsky [:bzbarsky]]

David, I don't see what any of that has to do with this bug.  There is a
different bug on synthetic click events not sending the right coords on an image
submit.

Comment 12

[carglue a t ya hoo do tcom]

Thanks Boris.  Its seemed related, but now I see that #282266 is a better 
choice.  I'll ammend that bug with some of this info, since not everyone may 
understand the full scope of this issue as it relates to CGI apps not being 
able to detect which image input element was selected on a submit.

Comment 13

[Gérard Talbot]

Testcase:

http://www.gtalbot.org/BugzillaSection/Bug69787EventOffsetXY.html

Comment 14

[Jez]

CCing self.

I'd definitely like to see this fixed.  Equivalent code to event.offsetX can be implemented in Javascript in Firefox, but it's a pain.  I'm attaching the equivalent.

Comment 15

[Jez]

Attachment: Equivalent to event.offset that works in FF

Attached equivalent code to event.offsetX / event.offsetY attributes, works in FF.

Comment 16

[John Resig]

We should strongly consider this. Currently we're the only browser that doesn't support this:
http://www.quirksmode.org/dom/w3c_cssom.html#elementviewm

Comment 17

[John Resig]

Also, this is part of the W3C CSSOM working draft:
http://www.w3.org/TR/cssom-view/

Comment 18

[Gérard Talbot]

IE's implementation of offsetParent changed with its IE 8 beta 1 release so calculations of offsetX, offsetY thanks to offsetParent is no longer reliable. 

IE's implementation of event.offsetX and event.offsetY has changed also with its IE 8 beta 1 release: IE 8 considers the content-box as the reference system while IE 7 and lower considers the padding-box as the reference system. 

http://www.w3.org/TR/cssom-view/
only treats the offsetParent, offsetLeft, offsetTop values; not the event.offsetX and event.offsetY

attachment 248546 [details] is not likely to work *_consistently_* if IE's implementation changed a lot. Also, the while condition can (will?) introduce an unwanted side effect with an assignment like 
while (elem = elem.offsetParent)

Comment 19

[Gérard Talbot]

I just noticed that
http://www.w3.org/TR/cssom-view/#the-mouseeventview-interface
defines offsetX and offsetY. So, we may need to resummarize this bug again... so that we can meet the CSSOM View specification instead of MSIE's model.

Comment 20

[Boris Zbarsky [:bzbarsky]]

That draft is not gospel.  If you think it's wrong (and arguably not being compatible with IE here is wrong), please raise it as an issue with the W3C.

Comment 21

[Martijn Wargers (dead)]

Attachment: totally failed attempt

This was a totally failed attempt of getting it working.
I need the element that the listener was registered to and get the coordinates from that frame.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #21)
> I need the element that the listener was registered to and get the coordinates
> from that frame.
Er, what listener? Why? The listener which is being handled?
Shouldn't you get the frame for the .target or .originalTarget?

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

I'm not sure the W3C draft is clear what should happen when a script creates
the event using document.createEvent("mouseevents")

Comment 25

[henryfhchan]

this has been in the specs for over 3 years already

Comment 26

[Jeff Muizelaar [:jrmuizel]]

(In reply to henry.fai.hang.chan from comment #25)
> this has been in the specs for over 3 years already

And is implemented by all browsers but Firefox.

Comment 27

[Olli Pettay [:smaug][[e-mail]]]

Patches welcome ;)

Comment 28

[Xiaoyi Shi]

this bug is 7 years old XD.

this should not be a tough one, just take the evt.target's on screen position (this should be available for painting purpose) and calculate with cursor's on screen position. 

but I have never downloaded Firefox's source code, and don't know where to start. Any one helps?

Comment 29

[Boris Zbarsky [:bzbarsky]]

https://developer.mozilla.org/en/Download_Mozilla_Source_Code

Comment 30

[Xiaoyi Shi]

Attachment: a straight forward implement of offsetX/Y, though not passing all the test cases.

After checked out the 1.2GB codebase, I took hours to find out the variables to use. I ended up with relPoint, which is calculated in nsPresShell, and nsEventStateManager. It supposed to corresponding to the offsetX/Y to the current event.target, but it fails when the target is a Table Element (TD, TR, etc.) or Input Element (INPUT etc.). I think it has something to do with their frame module, and I'm totally confused by the frame/widget/xxx. Any one helps to give a tip?

AND offsetX/Y are not stable in different browsers, like offsetX/Y of Anchor doesn't work in Chrome; the relative point of a wrapped element (eg. a span start at middle of first line and ends up at second line) they choose is quite interesting. 

Seems that the only browser get the offsetX/Y right, for now, is IE, according to http://www.quirksmode.org/dom/w3c_cssom.html.

Comment 31

[Boris Zbarsky [:bzbarsky]]

If I remember correctly refPoint is relative to the widget, no?  In this testcase:

  <!DOCTYPE html>
  <div style="height: 300px"></div>
  <div onclick="alert(event.offsetY)">Click me</div>

what kind of numbers does the alert show with the attached patch?

> the relative point of a wrapped element

Yeah, that's rather where the spec falls down.  If you can describe the actual IE behavior, that would be very helpful in terms of figuring out what the spec should say here.

And thank you for working on this!

Comment 32

[Xiaoyi Shi]

you got me, can you explain me a little about the widgets? I have to find another approach.

(In reply to Boris Zbarsky (:bz) from comment #31)
> If I remember correctly refPoint is relative to the widget, no?  In this
> testcase:
> 
>   <!DOCTYPE html>
>   <div style="height: 300px"></div>
>   <div onclick="alert(event.offsetY)">Click me</div>
> 
> what kind of numbers does the alert show with the attached patch?
> 
> > the relative point of a wrapped element
> 
> Yeah, that's rather where the spec falls down.  If you can describe the
> actual IE behavior, that would be very helpful in terms of figuring out what
> the spec should say here.
> 
> And thank you for working on this!

Comment 33

[Xiaoyi Shi]

ok... here I have a javascript fix... And I think this should work, and I will look into the source and make it implemented in binary.

Object.defineProperties(MouseEvent.prototype, {
  offsetX: {
    get: function() {
      return this.clientX - this.target.getBoundingClientRect().left;
    }
  },
  offsetY: {
    get: function() {
      return this.clientY - this.target.getBoundingClientRect().top;
    }
  }
});

this implementation works in the same way as chrome when dealing with wrapped elements.

Comment 34

[Boris Zbarsky [:bzbarsky]]

The widget thing isn't all that relevant if you do what you propose in comment 33, since getting the clientX/clientY handles the widget mess for you.

It's pretty easy to implement comment 33 directly, modulo the following questions:

1)  What should happen if this.target is display:none by that point?
2)  What does IE actually do?  If it does something saner than Chrome, we should try to do
    what it does...

Comment 35

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 604760 [details] [diff] [review]
a straight forward implement of offsetX/Y, though not passing all the test cases.

Per comments, this doesn't quite do the right thing in most cases...

Comment 36

[Xiaoyi Shi]

(In reply to Boris Zbarsky (:bz) from comment #34)
> The widget thing isn't all that relevant if you do what you propose in
> comment 33, since getting the clientX/clientY handles the widget mess for
> you.
> 
> It's pretty easy to implement comment 33 directly, modulo the following
> questions:
> 
> 1)  What should happen if this.target is display:none by that point?
> 2)  What does IE actually do?  If it does something saner than Chrome, we
> should try to do
>     what it does...

After a few test with IE9, it seems that offsetX/Y is not available all the time. IE failed some of the tests. like the offsetX/Y in TD, TR. And IE calculates offset based on the left top corner of the first line of a wrapped element instead of using the left top corner of the bound box.

About the display:none situation, is that event generated from script? otherwise I can't see how this possible to fire a event on a none displayed element. Any tips?

There is something weird about Firefox's BoundingClientRect().top/left, that it returns float instead of rounded integer sometimes(or all the times). Is that the proper action? I noticed that no other browser do the same.

And if we want to calculate offsetX/Y in IE's way, there is no reason to use BoundingClientRect() for it's complexity, the price of calculation would be very high.

Here is a extra test script can be run on any browser supports offsetX/Y. just to show the difference from implementation in comment 33.

Object.defineProperties(MouseEvent.prototype, {
  _offsetX: {
    get: function() {
      return this.clientX - this.target.getBoundingClientRect().left;
    }
  },
  _offsetY: {
    get: function() {
      return this.clientY - this.target.getBoundingClientRect().top;
    }
  }
});

var rollingStorage = new Array(100);
var index = 0;

window.addEventListener('mousemove', function(evt) {
  if (!(evt.offsetX == evt._offsetX && evt.offsetY == evt._offsetY)) {
    console.debug(evt.target, [evt.offsetX, evt._offsetX], [evt.offsetY, evt._offsetY], evt);
    var div = document.documentElement.appendChild(document.createElement('div'));
    div.style.position = 'absolute';
    div.style.left = evt.pageX-2 + 'px';
    div.style.top = evt.pageY-2 + 'px';
    div.style.width = '4px';
    div.style.height = '4px';
    div.style.borderRadius = '2px';
    div.style.backgroundColor = 'rgba(255,0,0,0.6)';
    if (rollingStorage[index])
      document.documentElement.removeChild(rollingStorage[index]);
    rollingStorage[index] = div;
    index = (index + 1) % rollingStorage.length;
  }
}, false);

Comment 37

[Xiaoyi Shi]

Here is a fix to make offsetX/Y work in completely the same way as Chrome.

Object.defineProperties(MouseEvent.prototype, {
  _offsetRelativeElement: {
    get: function() {
      var el = this.target;
      while (['block', 'inline-block', 'list-item', 'table', 'inline-table', 'table-caption', 'table-column', 'table-colgroup', 'table-header-group', 'table-row-group', 'table-footer-group', 'table-row', 'table-cell'].indexOf(window.getComputedStyle(el).display) == -1)
        el = el.parentNode;
      return el;
    }
  },
  _offsetX: {
    get: function() {
      return this.clientX - this._offsetRelativeElement.getBoundingClientRect().left;
    }
  },
  _offsetY: {
    get: function() {
      return this.clientY - this._offsetRelativeElement.getBoundingClientRect().top;
    }
  }
});

Comment 38

[Boris Zbarsky [:bzbarsky]]

> otherwise I can't see how this possible to fire a event on a none displayed element.

Events can trigger script that can then hide the element...  As simple example:

  <div 
    onclick="this.style.display = 'none'; document.body.offsetWidth; alert(event.offsetX)">
    Click me and see what's alerted
  </div>

> Is that the proper action?

It's what the spec calls for, yes.

> I noticed that no other browser do the same.

IE10 will do the same as I understand.

I agree that to do what IE does we don't need getBoundingClientRect; we really just want to do the equivalent of getClientRects()[0] but without the rect object being involved.  Look in nsGenericElement.cpp for how that's done?  Might need a bit of refactoring...

A side question: what happens when the event target is a textnode instead of an element?  Or do non-script-created mouse events always target elements?

Comment 39

[Xiaoyi Shi]

> I agree that to do what IE does we don't need getBoundingClientRect; we
> really just want to do the equivalent of getClientRects()[0] but without the
> rect object being involved.  Look in nsGenericElement.cpp for how that's
> done?  Might need a bit of refactoring...

I made a mistake about the test on IE. I tested it on IE8 instead of IE9. IE9 does almost the same as Chrome, with +-1px difference from the result in comment 37. So I changed a little to use clientLeft and clientTop to fix, but same result. There must be some other things need to be put into consideration. (may be I should test IE10 as well)

And about getClientRects(), I think it is unnecessary now, not for the relative point chosen reason. but for IE9 and chrome don't calculate offsetX/Y based on event.target if it's an inline element, instead it will find the first block element like the code in comment 37.

> display:none element

Chrome returns offsetX == clientX and offsetY == clientY, as evt.target.getBoundingClientRect().left = evt.target.getBoundingClientRect().top = 0. And IE still returns the offsets based ont evt.target.

> textnode
based on my tests, it always returns result based on the first parentNode which is a block element.

I put a test file in the attachment.

Comment 40

[Xiaoyi Shi]

Attachment: A test set

Comment 41

[4esn0k]

WebKit has "webkitConvertPointFromNodeToPage/webkitConvertPointFromPageToNode" API,
FLEX has localToGlobal/globalToLocal API, this api is much more useful, as it allows to get coordinates in coord. system relative to any element, even if css transforms was used.

Comment 42

[Joel Stevenson]

It's worth noting that although the code in comment 37 works nicely for untransformed elements it doesn't give the same results as the other browsers for transformed elements.  Per the cssom spec and the way the others implement it the offsetX/Y should return the position within the node *ignoring the transforms applied to the element* - so if you click on the far back corner of a box that has been skewed to give it a perspective of depth:

-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;

you get the offset coordinates within the box as if it weren't skewed.  This is very helpful bit of information to know in these cases.  

Currently it appears that FF's layerX/Y properties report this information for such transformed elements.

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is specced here: http://www.w3.org/TR/cssom-view/#dom-mouseevent-offsetx
People are using this. We should implement it.

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Implement MouseEvent.offsetX/Y

Comment 45

[Mats Palmgren (inactive)]

Comment on attachment 8569598 [details] [diff] [review]
Implement MouseEvent.offsetX/Y

r=mats with a minor nit:

>dom/events/Event.cpp
>+  nsIPresShell* shell = aPresContext->GetPresShell();

Please make that nsCOMPtr<nsIPresShell> because callers of
FlushPendingNotifications are expected to hold a strong ref.

==

The test is fine but could be more complete; for example testing that
an element with "transform:translateX(100px) scale(0)" returns 0,0
(i.e. the last return statement in GetOffsetCoords).  Also, an element
with "display:none".  Would it be possible to test also the
!mIsBeingDispatched path?  Edge cases like these are typically where
UAs are incompatible.

BTW, should this be a web-platform test?

==

I think you should send an "intent to ship" for this addition to the API,
to give people a chance to comment on potential web compat issues etc.

You should also get a DOM peer to review the DOM API changes in case
I missed something.

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Mats Palmgren (:mats) from comment #45)
> The test is fine but could be more complete; for example testing that
> an element with "transform:translateX(100px) scale(0)" returns 0,0
> (i.e. the last return statement in GetOffsetCoords).  Also, an element
> with "display:none".  Would it be possible to test also the
> !mIsBeingDispatched path?  Edge cases like these are typically where
> UAs are incompatible.

OK.

> BTW, should this be a web-platform test?

Currently testing/web-platform/README.md says
* I want to write some new tests for the web-platform-tests
  testsuite. How do I do that?

  See the section on tests below. At the moment you will have to
  submit the tests directly to the W3C and wait for them to be
  imported into the Mozilla tree.

So it doesn't seem possible add web-platform tests at the same time as the code.

> I think you should send an "intent to ship" for this addition to the API,
> to give people a chance to comment on potential web compat issues etc.

Done. We decided to make offsetX/Y integers to match other browsers.

> You should also get a DOM peer to review the DOM API changes in case
> I missed something.

Will do.

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Implement MouseEvent.offsetX/Y

Comment 48

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8574567 [details] [diff] [review]
Implement MouseEvent.offsetX/Y

I assume mats reviewed the coordinate handling.

Comment 49

[Olli Pettay [:smaug][[e-mail]]]

The spec needs to be fixed, double -> long, right?

Comment 50

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes.

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/43b9c8451378

Comment 52

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #46)
> > BTW, should this be a web-platform test?
> 
> Currently testing/web-platform/README.md says
> * I want to write some new tests for the web-platform-tests
>   testsuite. How do I do that?
> 
>   See the section on tests below. At the moment you will have to
>   submit the tests directly to the W3C and wait for them to be
>   imported into the Mozilla tree.
> 
> So it doesn't seem possible add web-platform tests at the same time as the
> code.

You can still write testharness.js tests that run as mochitests; see dom/imptests.

Comment 53

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/43b9c8451378

Comment 54

[Jean-Yves Perrier [:teoli]]

Updated/created:
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/offsetY
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/offsetX
and
https://developer.mozilla.org/en-US/Firefox/Releases/40

Note that the dev version of the spec has not yet been updated for the double -> long change.

Comment 55

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

roc is this worth mentioning in the release notes?  Thanks.

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No, I don't think so.

Comment 57

[Bill Chadwick]

Is this perhaps something to do with what has broken mousemove for maps not at 0,0 in Google Maps on V39 ?

Comment 58

[jkirk_14]

Not worth mentioning in release notes - nobody cares that google maps mouseevents will no longer work?  A bug was filed in beta before official 39 release.

Comment 59

[kolja]

Looks like the changes related to this ticket introduced a behaviour that drives developers of eg. Google Maps application nuts. Before FF 39 all different browsers reported the mouse over the upper left edge of a google map as 0,0. Since FF 39 you've got to subtract an offset depending on the parent elements. That definitely doesn't make sense as the mouse-event is related to the map element - not its whatsoever parents.

Problem named at stackoverflow
http://stackoverflow.com/questions/30651839/google-map-mouseevent-in-firefox-shows-incorrect-coordinates

Working example from the stackoverflow-question (use with FF39 - delivers wrong coords for upper left edge and FF before 39 or different browsers as google chrome - deliver right coords)
http://jsfiddle.net/fNPvf/15426/

Small problem. Big impact.

Comment 60

[Olli Pettay [:smaug][[e-mail]]]

Is the issue still on Google side, or do we report offsetX/Y differently to other browsers?

Comment 61

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's a Google bug. They feature-detect on offsetX and start doing crazy things. They say they're working on it.

Comment 62

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There's more information here: https://code.google.com/p/gmaps-api-issues/issues/detail?id=8278

Comment 63

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Disable offsetX/Y temporarily

We could land this patch on beta only to avoid the problem temporarily for the next release while Google gets their act together.

The risk, of course, is that Google just stops caring (or never did) and it becomes impossible for us to implement offsetX/Y ever.

Comment 64

[Patrick H. Lauke]

Wondering if [e-mail] could have a word with the maps team...

Comment 65

[kolja]

Bug is to be found WITHIN THE GOOGLE MAPS API.

Hint for users of Google Maps: Adding parameter v=3 solves that behaviour with GMaps. v=3.exp does NOT work.

<script src="https://maps.googleapis.com/maps/api/js?v=3"></script>

See working example - correct:
http://jsfiddle.net/fNPvf/17008/

See non-working example:
http://jsfiddle.net/fNPvf/15426/

Comment 66

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0f598f4df08c

Comment 67

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: updated patch to disable offsetX/Y

Approval Request Comment
[Feature/regressing bug #]: 69787
[User impact if declined]: Many embedded Google Maps do not work
[Describe test coverage new/current, TreeHerder]: Try run is green
[Risks and why]: It's possible, albeit very unlikely, that some sites have changed so that they don't work on Firefox with offsetX/Y disabled. The other risk is that landing this, even for just one release, demotivates Google to actually fix their code. I'm not 100% sure we should actually land this, it's not good to have a feature exist for one release and then disappear hopefully to come back a release later.
[String/UUID change made/needed]: None

Comment 68

[kolja]

FYI: The solution mentioned before calling GMaps-API with param v=3 does NOT work anymore. Looks like somebody at google changed something. GMaps-Errors are back.

Sideeffect: As users want to use pages which rely on GMaps, they have to switch to Non-Firefox-Browsers - probably Google's Chrome in many cases.

That means:
a) thousands of users just for one GMaps-page don't use the former leading browser FF anymore - from one day to the other (i experience exactly that with my page) and
b) Google's Chrome get's pushed as long as that problem isn't fixed...

Comment 69

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #67)
> [Risks and why]: It's possible, albeit very unlikely, that some sites have
> changed so that they don't work on Firefox with offsetX/Y disabled. The
> other risk is that landing this, even for just one release, demotivates
> Google to actually fix their code. I'm not 100% sure we should actually land
> this, it's not good to have a feature exist for one release and then
> disappear hopefully to come back a release later.

I don't know that we should do this either. Typically our conversations with Google go well in terms of producing fixes for issues like this. If we are going to put a hack in 40 to better support maps, can we restrict the change in behaviour to Google Maps only?

Comment 70

[jkirk_14]

v=3 still working for me.  I definitely don't view this as a solution, but a workaround until 3.exp is corrected.

Comment 71

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #69)
> I don't know that we should do this either. Typically our conversations with
> Google go well in terms of producing fixes for issues like this. 

I pinged our Google contact for an update. I'm not going to take this change in beta8 as I would like to hear from Google first. We can consider this fix for beta9 if need be.

> If we are
> going to put a hack in 40 to better support maps, can we restrict the change
> in behaviour to Google Maps only?

Seems this isn't an option as the script is simply loaded from the maps domain.

Comment 72

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #69)
> I don't know that we should do this either. Typically our conversations with
> Google go well in terms of producing fixes for issues like this. If we are
> going to put a hack in 40 to better support maps, can we restrict the change
> in behaviour to Google Maps only?

We've been talking to Google for months and so far the only concrete results are that they've disabled the workaround people were using (comment #68) :-(.

Comment 73

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Or maybe not. But still, it's not looking good.

Comment 74

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8638453 [details] [diff] [review]
updated patch to disable offsetX/Y

Somewhat more positive news about Google via e-mail with Roc. We take a risk whether we take this change or not. As I think we'd all rather end up on the side where we don't have to take this patch, I think that's the approach that we should take for now. This is the type of change that we can push with an add-on hotfix so that should be our fallback if we don't see the progress with fixing Google Maps that we expect. Beta-

Comment 75

[Jean-Yves Perrier [:teoli]]

Lawrence: I've a doubt here. I've marked this feature as fixed in Fx 40 for developers. Is this correct? I see Firefox39 in the field. 

(Turning dev-doc-needed back on so I have it again on our radar)

Comment 76

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Jean-Yves Perrier [:teoli] from comment #75)
> Lawrence: I've a doubt here. I've marked this feature as fixed in Fx 40 for
> developers. Is this correct? I see Firefox39 in the field. 

This bug was fixed in 39 (comment 53). We were debating backing this out in 40 but decided against that (comment 74).

Comment 77

[Jean-Yves Perrier [:teoli]]

Thanks Lawrence, the docs are updated:
https://developer.mozilla.org/en-US/Firefox/Releases/39#InterfacesAPIsDOM
and
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/offsetX
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/offsetY

I also noted the fact that for Mobile, it has later been backed out (and relanded for Firefox 43).

Comment 78

[Julien Wajsberg [:julienw]]

Is it worth filing a separate bug to implement offsetX/offsetY on touches as well ?