Chris Bodart Reporter
	Description • 24 years ago

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!!)

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 24 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 24 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 24 years ago

we now have some new DOM components...

	Johnny Stenback (:jst)
	Comment 5 • 23 years ago

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

	Johnny Stenback (:jst)
	Comment 6 • 23 years ago

Really reassigning this time.

	Gérard Talbot
	Comment 7 • 19 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 19 years ago

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.

	Gérard Talbot
	Comment 9 • 19 years ago

> 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

	carglue a t ya hoo do tcom
	Comment 10 • 19 years ago

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).

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 19 years ago

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.

	carglue a t ya hoo do tcom
	Comment 12 • 19 years ago

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.

	Gérard Talbot
	Comment 13 • 19 years ago

Testcase:

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

	Jez
	Comment 14 • 18 years ago

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.

	Jez
	Comment 15 • 18 years ago

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

	John Resig
	Comment 16 • 16 years ago

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

	John Resig
	Comment 17 • 16 years ago

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

	Gérard Talbot
	Comment 18 • 16 years ago

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)

	Gérard Talbot
	Comment 19 • 16 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 20 • 16 years ago

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.

	Martijn Wargers (dead)
	Comment 21 • 16 years ago

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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 22 • 16 years ago

(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?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 23 • 16 years ago

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

	henryfhchan
	Comment 25 • 12 years ago

this has been in the specs for over 3 years already

	Jeff Muizelaar [:jrmuizel]
	Comment 26 • 12 years ago

(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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 27 • 12 years ago

Patches welcome ;)

	Xiaoyi Shi
	Comment 28 • 12 years ago

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?

	Boris Zbarsky [:bzbarsky]
	Comment 29 • 12 years ago

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

	Xiaoyi Shi
	Comment 30 • 12 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 31 • 12 years ago

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!

	Xiaoyi Shi
	Comment 32 • 12 years ago

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!

	Xiaoyi Shi
	Comment 33 • 12 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 34 • 12 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 35 • 12 years ago

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

	Xiaoyi Shi
	Comment 36 • 12 years ago

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

	Xiaoyi Shi
	Comment 37 • 12 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 38 • 12 years ago

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

	Xiaoyi Shi
	Comment 39 • 12 years ago

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

	4esn0k
	Comment 41 • 12 years ago

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.

	Joel Stevenson
	Comment 42 • 9 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 43 • 9 years ago

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

	Mats Palmgren (inactive)
	Comment 45 • 9 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 46 • 9 years ago

(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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 48 • 9 years ago

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

I assume mats reviewed the coordinate handling.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 49 • 9 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 50 • 9 years ago

Yes.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 51 • 9 years ago

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

	:Ms2ger (he/him; ⌚ UTC+1/+2)
	Comment 52 • 9 years ago

(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.

	Ryan VanderMeulen [:RyanVM]
	Comment 53 • 9 years ago

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

	Jean-Yves Perrier [:teoli]
	Comment 54 • 9 years ago

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.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 55 • 9 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 56 • 9 years ago

No, I don't think so.

	Bill Chadwick
	Comment 57 • 9 years ago

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

	jkirk_14
	Comment 58 • 9 years ago

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.

	kolja
	Comment 59 • 9 years ago

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.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 60 • 9 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 61 • 9 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 62 • 9 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 63 • 9 years ago

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.

	Patrick H. Lauke
	Comment 64 • 9 years ago

Wondering if rbyers@chromium.org could have a word with the maps team...

	kolja
	Comment 65 • 9 years ago

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/

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 66 • 9 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 67 • 9 years ago

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

	kolja
	Comment 68 • 9 years ago

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

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 69 • 9 years ago

(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?

	jkirk_14
	Comment 70 • 9 years ago

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

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 71 • 9 years ago

(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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 72 • 9 years ago

(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) :-(.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 73 • 9 years ago

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

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 74 • 9 years ago

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-

	Jean-Yves Perrier [:teoli]
	Comment 75 • 9 years ago

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)

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 76 • 9 years ago

(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).

	Jean-Yves Perrier [:teoli]
	Comment 77 • 9 years ago

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).

	Julien Wajsberg [:julienw]
	Comment 78 • 9 years ago

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