Open Bug 1359440 Opened 8 years ago Updated 4 months ago

MouseEvent.offsetX and offsetY are only available on the current event, not on all events

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Version:
53 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: s.marechal, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170414022702 Steps to reproduce: I have a created JSFiddle to show the issue: https://jsfiddle.net/69md71e0/1/ Watch the JS console, then use the mouse scrollwheel when hovering over the indicated div. Actual results: The previousEvent variable always has offsetX and offsetY as 0 Expected results: The offsetX and offsetY should either be: - The same as the offsetX/Y from the last time the event was logged. or, strictly following the spec at https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx - The value of the pageX/pageY properties.
Component: Untriaged → DOM: Events
Product: Firefox → Core
Could this be something related to bug 1350373?
Flags: needinfo?(bugs)
Related yes, but also that we don't cache the offsetX/Y in UIEvent::DuplicatePrivateData(). Perhaps UIEvent::DuplicatePrivateData() could cache the information, but _not_ flush layout.
Flags: needinfo?(bugs)
Or hmm, should Event::GetOffsetCoords return page coords when event is not being dispatched.
Assignee: nobody → bugs
The spec has also other bugs, not just https://github.com/w3c/csswg-drafts/issues/1070 but I'll do the simple fix here for now.
Oh, I don't know if any browser follows the spec.
Assignee: bugs → nobody
So, it is totally unclear whether this bug is valid or not.
Priority: -- → P3

I've also encountered this bug. Here's another jsfiddle that prints the value immediately and after a setTimeout(..., 0):
https://jsfiddle.net/winstonchang/L1kxwsg6/11/

It certainly seems that it shouldn't be returning 0.

Because of this bug, yesterday I spent a good amount of time wondering "wtf?!". In Chrome it's working perfectly fine:

But for Firefox...

Here is a JSFiddle to test it yourself:
https://jsfiddle.net/marverix/oy7gvatb/13/

Like, I don't understand - why you are "zeroing" those values? Is there a good reason for that? Or specification that says to do so?

My workaround for this bug is that I need manually copy those primitive values to other variables...

Sorry for double-post, but I see that Markdown Images are not supported... so...
Chrome:
https://i.ibb.co/9WrnXc4/screenshot-2.png
Firefox:
https://i.ibb.co/KN2MWPf/screenshot-3.png

Severity: normal → S3

I think I just duplicated this bug with this report: https://bugzilla.mozilla.org/show_bug.cgi?id=1871988

I will add a vote to this report, feel free to mark my report as a dup of this earlier one.

But you left this for SEVEN YEARS???

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #3)

Or hmm, should Event::GetOffsetCoords return page coords when event is not
being dispatched.

Why should it be a getter? These are fixed values once the event has happened. The event happened at that point inside the target. Just cache the actual offsets and offer them as public read-only properties.

I see that you refer to the spec:

The offsetX attribute must follow these steps:

If the event’s dispatch flag is set, return the x-coordinate of the position where the event occurred relative to the origin of the padding edge of the target node, ignoring the transforms that apply to the element and its ancestors, and terminate these steps.

Return the value of the event’s pageX attribute.

Don't be so obsessive. Blink and WebKit wisely ignore this.

In this case the spec needs to be changed. There is absolutely no use case for the values dropping to zero.

Duplicate of this bug: 1882903
You need to log in before you can comment on or make changes to this bug.