Bug 174561 – clientX/clientY on TouchEvent.touches are wrong

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Simon Fraser (smfr)]

clientX/clientY on TouchEvent.touches are wrong

[Simon Fraser (smfr)]

Created attachment 315593 [details]
Patch

[Simon Fraser (smfr)]

rdar://problem/33336041

[Build Bot]

Comment on attachment 315593 [details]
Patch

Attachment 315593 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/4129364

New failing tests:
storage/websql/execute-sql-rowsAffected.html
http/tests/canvas/philip/tests/security.pattern.canvas.fillStyle.html

[Build Bot]

Created attachment 315596 [details]
Archive of layout-test-results from ews124 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews124  Port: ios-simulator-wk2  Platform: Mac OS X 10.12.5

[Simon Fraser (smfr)]

https://trac.webkit.org/r219571

[Darin Adler]

Comment on attachment 315593 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=315593&action=review

> Source/WebCore/dom/MouseRelatedEvent.h:69
> +    static FrameView* frameViewFromDOMWindow(DOMWindow*);

This seems inferior to the old frameView function. Harder to call, never used in a way that is any different from what the old function would have done since it’s always passed view(). I don’t understand why we changed this.

[Simon Fraser (smfr)]

(In reply to Darin Adler from comment #6)
> Comment on attachment 315593 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=315593&action=review
> 
> > Source/WebCore/dom/MouseRelatedEvent.h:69
> > +    static FrameView* frameViewFromDOMWindow(DOMWindow*);
> 
> This seems inferior to the old frameView function. Harder to call, never
> used in a way that is any different from what the old function would have
> done since it’s always passed view(). I don’t understand why we changed this.

It's called from Apple internal code that's inserted via WebKitAdditions for touch handling, in classes that don't inherit from MouseRelatedEvent (or have one).

[Darin Adler]

(In reply to Simon Fraser (smfr) from comment #7)
> > This seems inferior to the old frameView function. Harder to call, never
> > used in a way that is any different from what the old function would have
> > done since it’s always passed view(). I don’t understand why we changed this.
> 
> It's called from Apple internal code

Got it.