Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Invalid pageX and pageY properties returned in non-mouse events on Firefox #3692
This is probably a Firefox issue more than a jQuery issue, but it seems to be a regesseion in that it's something that jQuery used to handle but no longer does.
With the latest version of jQuery I am finding that invalid
The issue only manifests in Firefox for me. Chromium and IE don't seem to have the problem. Firefox does include the invalid
This was causing a bug in one of my jQuery plugins (stevenbenner/jquery-powertip#158).
Link to test case
This checks what the type and value of the
Firefox 52.0 32-bit Windows (no add-ons) and Firefox 53.0.3 64-bit Linux (lots of add-ons):
Chromium 58, Internet Explorer 11
referenced this issue
Jun 11, 2017
@stevenbenner I've pinged the twitter webcompat account about this via https://twitter.com/davemethvin/status/874008700205363200 to see if this should properly be undefined for a focus event. The reason you're seeing it only on jQuery 3 is because we now transparently/lazily return more properties from the original event and as your test case shows the value is
Thanks. I'm interested to hear peoples thoughts on this.
Based on the MDN docs, I suspect that these properties are included in Firefox because the FocusEvent inherits from UIEvent, and in their implementation that includes UIEvent.pageX (note that the doc page has a warning that it is non-standard). These properties are probably only trustworthy when coming from a MouseEvent (e.g. MouseEvent.pageX).
So it certainly looks like Firefox is not to spec on this one.
Is this the type of thing that jQuery should normalize? A fix should be fairly trivial to implement, but hacky since the value of these properties cannot be trusted. My workaround was to compare the event type to a list of events that would be expected to include cursor position data, and ignore the coordinate properties included with any events that are not matched.
Just about all the browsers are on a fast update cycle nowadays. If this is a compat issue it should be fixed by Firefox relatively quickly. It seems like an obscure enough issue that code sensitive to this should be able to check for it. Since events can occur at a high frequency, jQuery tries to keep extra code out of that path.
Ah also Safari Version 10.1.1 (12603.2.4) and Safari Tech Preview Release 32 (Safari 11.0, WebKit 12604.1.23.0.4) return the same results than Firefox.
I don't want to have to keep a list of all appropriate event types (or even a blacklist), because that's not future-proof. It seems clear to me that we're doing the right thing here. We're even returning the property value lazily, meaning we no longer copy over this property ahead of time. That is a step in the right direction and possibly the best course we can take. Since the value isn't reliable or useful to any user, this is not a high priority issue. It's unlikely we'll change anything here.