Closed
Bug 69787
Opened 23 years ago
Closed 8 years ago
Implement MSIE's event.offsetX, event.offsetY as mouse coordinates inside target element
Categories
(Core :: DOM: Events, enhancement, P4)
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: chris, Assigned: roc)
References
(Blocks 2 open bugs, )
Details
(Keywords: dev-doc-complete, testcase)
Attachments
(6 files, 3 obsolete files)
317 bytes,
text/html
|
Details | |
826 bytes,
text/plain
|
Details | |
2.79 KB,
text/plain
|
Details | |
9.83 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
1.00 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
2.52 KB,
patch
|
lmandel
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
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!!)
![]() |
||
Updated•23 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
![]() |
||
Comment 1•23 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 ***
![]() |
||
Comment 2•23 years ago
|
||
Reopening. offsetLeft and company are indeed not defined for mouse events. My apologies.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
![]() |
||
Comment 3•23 years ago
|
||
![]() |
||
Comment 4•23 years ago
|
||
we now have some new DOM components...
Assignee: joki → jst
Status: UNCONFIRMED → NEW
Component: Event Handling → DOM Events
Ever confirmed: true
Keywords: dom2
QA Contact: gerardok → ian
Comment 5•23 years ago
|
||
Reassigning to joki and Futuring based on a discussion with him.
Target Milestone: --- → Future
Updated•21 years ago
|
Severity: normal → enhancement
Priority: -- → P4
Comment 7•18 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
Status: NEW → RESOLVED
Closed: 23 years ago → 18 years ago
Resolution: --- → INVALID
![]() |
||
Comment 8•18 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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 9•18 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
Keywords: dom2
Summary: DOM Spec for events is lacking offset Support (as it is/was lacking offsetParent etc) → Implement MSIE's event.offsetX, event.offsetY as mouse coordinates inside target element
Whiteboard: http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/offsetx.asp
Comment 10•18 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).
![]() |
||
Comment 11•18 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.
Comment 12•18 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.
Comment 13•18 years ago
|
||
Testcase: http://www.gtalbot.org/BugzillaSection/Bug69787EventOffsetXY.html
Keywords: testcase
Updated•17 years ago
|
Assignee: joki → events
Status: REOPENED → NEW
OS: Other → All
Whiteboard: http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/offsetx.asp
Comment 14•17 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.
Comment 15•17 years ago
|
||
Attached equivalent code to event.offsetX / event.offsetY attributes, works in FF.
Comment 16•15 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
Comment 17•15 years ago
|
||
Also, this is part of the W3C CSSOM working draft: http://www.w3.org/TR/cssom-view/
Comment 18•15 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)
Comment 19•15 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.
![]() |
||
Comment 20•15 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.
Comment 21•15 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.
Updated•15 years ago
|
Attachment #312285 -
Attachment is patch: true
Attachment #312285 -
Attachment mime type: application/octet-stream → text/plain
Comment 22•15 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?
Comment 23•15 years ago
|
||
I'm not sure the W3C draft is clear what should happen when a script creates the event using document.createEvent("mouseevents")
Updated•14 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 25•12 years ago
|
||
this has been in the specs for over 3 years already
Comment 26•11 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.
Comment 27•11 years ago
|
||
Patches welcome ;)
Comment 28•11 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?
Comment 30•11 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.
Updated•11 years ago
|
Attachment #604760 -
Flags: feedback?(bzbarsky)
![]() |
||
Comment 31•11 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!
Comment 32•11 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!
Comment 33•11 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.
![]() |
||
Comment 34•11 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...
![]() |
||
Comment 35•11 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...
Attachment #604760 -
Flags: feedback?(bzbarsky) → feedback-
Comment 36•11 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);
Comment 37•11 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; } } });
![]() |
||
Comment 38•11 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?
Comment 39•11 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.
Comment 40•11 years ago
|
||
Updated•11 years ago
|
Target Milestone: Future → mozilla16
Version: Trunk → Other Branch
Comment 41•11 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.
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.
Assignee | ||
Comment 43•8 years ago
|
||
This is specced here: http://www.w3.org/TR/cssom-view/#dom-mouseevent-offsetx People are using this. We should implement it.
Assignee | ||
Comment 44•8 years ago
|
||
Assignee: nobody → roc
Attachment #312285 -
Attachment is obsolete: true
Attachment #604760 -
Attachment is obsolete: true
Attachment #8569598 -
Flags: review?(mats)
Updated•8 years ago
|
Keywords: dev-doc-needed
Comment 45•8 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.
Attachment #8569598 -
Flags: review?(mats) → review+
Assignee | ||
Comment 46•8 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.
Assignee | ||
Comment 47•8 years ago
|
||
Attachment #8574567 -
Flags: review?(bugs)
Assignee | ||
Updated•8 years ago
|
Attachment #8569598 -
Attachment is obsolete: true
Comment 48•8 years ago
|
||
Comment on attachment 8574567 [details] [diff] [review] Implement MouseEvent.offsetX/Y I assume mats reviewed the coordinate handling.
Attachment #8574567 -
Flags: review?(bugs) → review+
Comment 49•8 years ago
|
||
The spec needs to be fixed, double -> long, right?
Assignee | ||
Comment 50•8 years ago
|
||
Yes.
Assignee | ||
Comment 51•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/43b9c8451378
Comment 52•8 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.
Comment 53•8 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/43b9c8451378
Status: NEW → RESOLVED
Closed: 18 years ago → 8 years ago
status-firefox39:
--- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Comment 54•8 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.
Keywords: dev-doc-needed → dev-doc-complete
Updated•8 years ago
|
Target Milestone: mozilla16 → mozilla39
roc is this worth mentioning in the release notes? Thanks.
Flags: needinfo?(roc)
Comment 57•8 years ago
|
||
Is this perhaps something to do with what has broken mousemove for maps not at 0,0 in Google Maps on V39 ?
Comment 58•8 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.
Comment 59•8 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.
Comment 60•8 years ago
|
||
Is the issue still on Google side, or do we report offsetX/Y differently to other browsers?
Flags: needinfo?(roc)
Flags: needinfo?(rbyers)
Assignee | ||
Comment 61•8 years ago
|
||
It's a Google bug. They feature-detect on offsetX and start doing crazy things. They say they're working on it.
Flags: needinfo?(roc)
Assignee | ||
Comment 62•8 years ago
|
||
There's more information here: https://code.google.com/p/gmaps-api-issues/issues/detail?id=8278
Assignee | ||
Comment 63•8 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.
Attachment #8637539 -
Flags: review?(bugs)
Comment 64•8 years ago
|
||
Wondering if rbyers@chromium.org could have a word with the maps team...
Comment 65•8 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/
Updated•8 years ago
|
Attachment #8637539 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 66•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=0f598f4df08c
Assignee | ||
Comment 67•8 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
Attachment #8638453 -
Flags: approval-mozilla-beta?
Comment 68•8 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...
Comment 69•8 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?
Flags: needinfo?(roc)
Comment 70•8 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.
Comment 71•8 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.
Assignee | ||
Comment 72•8 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) :-(.
Flags: needinfo?(roc)
Assignee | ||
Comment 73•8 years ago
|
||
Or maybe not. But still, it's not looking good.
Comment 74•8 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-
Attachment #8638453 -
Flags: approval-mozilla-beta? → approval-mozilla-beta-
Comment 75•8 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)
Flags: needinfo?(lmandel)
Keywords: dev-doc-complete → dev-doc-needed
Comment 76•8 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).
Flags: needinfo?(lmandel)
Comment 77•8 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).
Keywords: dev-doc-needed → dev-doc-complete
Comment 78•8 years ago
|
||
Is it worth filing a separate bug to implement offsetX/offsetY on touches as well ?
Updated•5 years ago
|
Flags: needinfo?(rbyers)
You need to log in
before you can comment on or make changes to this bug.
Description
•