Touch Events pageX, pageY Behavior Differences

[Ted Dinklocker]

Esteemed Chromium Developers,

 

We ran into an interoperability issue (on viewing an image carousel on bing.com) and have noticed an inconsistency between how Chrome and Edge populate the event.pageX and event.pageY properties for the touchmove event.

 

Microsoft Edge returns undefined for these attributes, while Chrome reports 0 for these attributes. The spec is silent on requirements for these attributes on the events. I have attached the simplified repro, but you can also just use http://teddin.azurewebsites.net/test/TouchPageXY.html to see the behavior.

 

If you want to try it on a recent build of Microsoft Edge, make sure that you go to about:flags and turn on touch events on desktop.

 

We would like to discuss a consistent implementation here. We feel that undefined is correct, but consistent is more important.

 

How would you like to proceed?

 

Thanks and look forward to working with you on this issue.

 

Ted

 

Ted Dinklocker
Senior Program Manager Internet Explorer Platform	Office: +1 (425) 703-8577 Ted.Din...@microsoft.com

 

[Rick Byers]

Thanks for reaching out Ted!

At first I thought you were talking about Touch.pageX (which would be a crazy bug if it was always 0).  But of course you're talking on the TouchEvent object itself (which inherits from UIEvent which is where pageX is defined in blink).  It looks like we also expose layerX/layerY on UIEvent as well.  So TouchEvent.prototype.hasOwnProperty('pageX') is false, but UIEvent.protototype.hasOwnProperty('pageX') is true in blink.

TouchEvent.prototype.haspageX/pageY and layerX/layerY aren't specified anywhere, right?  I agree that ideally these should not be defined on UIEvent since they don't make sense for events that don't have distinct co-ordinates.  My only concern with changing this would be risk of breaking some sites.  Do you define these all directly on MouseEvent?  Is Bing.com the only site you've found with issues here?  How much compat data do you have?

If you have reason to believe that it's largely web compatible to have pageX/pageY (and layerX/layerY) defined on MouseEvent instead of UIEvent then I'm happy to try moving them and see how it goes.  FWIW we have metrics showing that pageX/pageY are used on 16% of page loads while layerX/layerY are used on 2%.  But we don't track what fraction of these are MouseEvents.

Rick

[Jacob Rossi]

My read of this is that Blink just has these properties on the wrong interface. CSS OM View says these go on MouseEvent (which is why we inherit them on PointerEvent too) rather than UIEvent. 

 

http://www.w3.org/TR/cssom-view/#extensions-to-the-mouseevent-interface

[Rick Byers]

Oh, whoops - I forgot these got added in CSS OM View.  Yes, we should definitely just try to change this.  Filed http://crbug.com/503274.  But still, any compat data you have (including if/when Bing will be updated not to be broken by this) will be helpful here in our "intent to ship" process.

Thanks,

  Rick

[Dave Tapuska]

They seem to only be populated by MouseRelatedEvent which is WheelEvent, MouseEvent and GestureEvent. Otherwise they return 0.

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Rick Byers]

Ah, at one point a long time ago I changed TouchEvent so it wasn't a MouseRelatedEvent.  It may have gotten non-zero values then, but apparently I didn't break anyone :-).  Sorry I didn't notice this issue at the time.

FWIW, based on this discussion I've also filed a similar bug for layerX/layerY and another to make 'scroll' a UIEvent (only once this bug is fixed).

[Ted Dinklocker]

Great minds clearly think alike – Jacob also thought I was talking about touch.pageX when he first read my email J

 

Doing a cursory search through our code, it appears that we only define pageX/pageY and layerX/layerY on the mouseevent objects.

 

As far as I know, the bing.com issue was the first one that we have run into that had this problem – but it was a direct customer feedback report, not a telemetry find. I am digging into other data that we have on usage and reported bugs to see if there are other instances lurking (or just more data to be had) – stay tuned on that. Bing has already fixed the issue on their side – Chrome and Edge both work the same now, as expected, with the picture carousel (see https://www.bing.com/images/search?q=cocker+spaniel+puppies&view=detailv2&id=2220B1AF84694E8262968DD4D0F9EF82F62AF55E&selectedindex=5&ccid=kLPhtZ4B&simid=608009533905045975&thid=JN.NVcRyh1qEVOXtHEJ7EAIOA&mode=overlay&first=1 for an example, if you would like).

 

Ted

[Rick Byers]

Great, thanks for the data!  I'll find someone to try fixing this ASAP.

Rick

[Kartikaya Gupta]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1178763 to fix this in Gecko as well; we appear to be returning the scroll position via pageX and pageY which is wrong in a whole different way :)

Cheers,

kats

[Rick Byers]

FYI Dave landed this fix last week and you can see it in current canary builds (eg. 45.0.2451.0 or later).  Star the bug to be notified if we come across any compat issues as a result (but my gut instinct is that this change will stick).

Rick