Bug 100270
| Summary: | Explore the possibility of re-naming GestureLongPress and GestureTwoFingerTap to GestureContextMenu in WebCore | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Terry Anderson <tdanderson> |
| Component: | UI Events | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | abarth, ahmad.saleem792, allan.jensen, ap, rjkroege, sadrul, tonikitoo, varunjain |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Terry Anderson
It was suggested by Allan Jensen in https://bugs.webkit.org/show_bug.cgi?id=99947#c5 that WebCore should re-name GestureLongPress and GestureTwoFingerTap to GestureContextMenu in WebCore. Let's discuss that idea here.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adam Barth
That seems in line with things like GestureScroll.
Varun Jain
two questions:
1. will (can) this also include right-click with mouse?
2. currently, GestureLongPress means different things on different platforms (different handling on android). The deciding code will have to be moved to WebViewImpl if we were to go with GestureContextMenu. IIRC, the reviewers were opposed to it when that was added. How do we handle that?
Sadrul Habib Chowdhury
I think the idea here is that the WebCore gestures will represent the desired action, rather than the gesture itself. So for example, for a LongPress event, WebCore will receive a GestureSelectWord (or something similar) on android, while a GestureContextMenu on other platforms.
Allan Sandfeld Jensen
(In reply to comment #2)
> two questions:
> 1. will (can) this also include right-click with mouse?
> 2. currently, GestureLongPress means different things on different platforms (different handling on android). The deciding code will have to be moved to WebViewImpl if we were to go with GestureContextMenu. IIRC, the reviewers were opposed to it when that was added. How do we handle that?
1. No, this is for gestures that need touch-adjustment to elements relevant to context-menu. Though we I guess we could improve code sharing with right-click and the Windows ContextMenu button.
2. The way I see gesture events is like this:
You have touch events that go into gesture recognizers, they output possible gestures in different states: MayBegin, Start, Update, End, Cancel. If you have code that decides between different actions it will either postpone sending a start event, or it will send a cancel event when the gesture turns out to be something else.
Robert Kroeger
I like Sadrul's organizing principle: let the embedder decide what causes an action, let WebCore implement the action. In Chrome's context, I think we need perhaps both of:
GestureContextMenu
and perhaps:
GestureStartSelection (as opposed to GestureSelectWord) and because it admits a GestureEndSelection which might also be useful.
and embedder or WebKit logic can choose when to send the respective Platform events.
Thoughts?
Terry Anderson
Created a duplicate of this bug for Blink at crbug.com/226492.
Ahmad Saleem
Chrome / Blink bug mentioned following rationale to not go ahead with this change:
"I am not sure thats a good idea. Longpress is going to be overloaded for drag drop and text selection. two finger tap will not."
Link - https://bugs.chromium.org/p/chromium/issues/detail?id=226492#c3
Something required by WebKit or we can mark this as "RESOLVED LATER" or "RESOLVED WONTFIX"? Thanks!
Alexey Proskuryakov
A refactoring discussion from 2012 isn't really relevant today.