Bug 185282 – Allow Web Touch events to timeout

• Component: New Bugs
• Status: RESOLVED FIXED

[Megan Gardner]

Allow Web Touch events to timeout

[Megan Gardner]

Created attachment 339495 [details]
Patch

[Megan Gardner]

<rdar://problem/38728319>

[Tim Horton]

I think you should consider writing a test for this. Might need to add a mechanism to speed up timeouts (like the one we have to make them go to ∞).

[Tim Horton]

ignoreSynchronousMessagingTimeoutsForTesting

[WebKit Commit Bot]

Comment on attachment 339495 [details]
Patch

Clearing flags on attachment: 339495

Committed r231370: <https://trac.webkit.org/changeset/231370>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Wenson Hsieh]

Comment on attachment 339495 [details]
Patch

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

> Source/WebKit/UIProcess/WebPageProxy.cpp:2303
> +        handled = true;

I don't think this is quite right, since it would mean any touchstart that is dispatched to the page would behave as though the page called preventDefault(). This would prevent clicks when tapping on elements that have touch event handlers, but do not preventDefault() (e.g. links on Google search result pages).

[Tim Horton]

Comment on attachment 339495 [details]
Patch

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

>> Source/WebKit/UIProcess/WebPageProxy.cpp:2303
>> +        handled = true;
> 
> I don't think this is quite right, since it would mean any touchstart that is dispatched to the page would behave as though the page called preventDefault(). This would prevent clicks when tapping on elements that have touch event handlers, but do not preventDefault() (e.g. links on Google search result pages).

Only if it times out, though? We thought that mostly made sense. I’ll add you to a thread about it.

[Wenson Hsieh]

Comment on attachment 339495 [details]
Patch

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

>>> Source/WebKit/UIProcess/WebPageProxy.cpp:2303
>>> +        handled = true;
>> 
>> I don't think this is quite right, since it would mean any touchstart that is dispatched to the page would behave as though the page called preventDefault(). This would prevent clicks when tapping on elements that have touch event handlers, but do not preventDefault() (e.g. links on Google search result pages).
> 
> Only if it times out, though? We thought that mostly made sense. I’ll add you to a thread about it.

Yeah, I think the plan makes sense (treat IPC time out as if default was prevented).

Perhaps I'm missing something, but this change seems to make it so that as long as `replyReceived` is true (e.g. the IPC message didn't time out), then we set handled to true (i.e. treat it as if the page called preventDefault()).

[Tim Horton]

Haha, I see, yes, it’s backwards :/

[Tim Horton]

How in the world did that not cause a single test failure?!?

[Wenson Hsieh]

(In reply to Tim Horton from comment #12)
> How in the world did that not cause a single test failure?!?

Touch-event-related tests cannot run on the open source bots :/

That said, our internal test runners are looking quite red...

[Megan Gardner]

https://trac.webkit.org/changeset/231447/webkit