100270 2012-10-24 11:07:06 -0700 Explore the possibility of re-naming GestureLongPress and GestureTwoFingerTap to GestureContextMenu in WebCore 2022-09-29 17:59:45 -0700 1 1 1 Unclassified WebKit UI Events 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 tdanderson webkit-unassigned abarth ahmad.saleem792 allan.jensen ap rjkroege sadrul tonikitoo varunjain oldest_to_newest 749839 0 tdanderson 2012-10-24 11:07:06 -0700 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. 749843 1 abarth 2012-10-24 11:09:43 -0700 That seems in line with things like GestureScroll. 749852 2 varunjain 2012-10-24 11:19:28 -0700 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? 749858 3 sadrul 2012-10-24 11:25:43 -0700 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. 750578 4 allan.jensen 2012-10-25 02:20:09 -0700 (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. 758740 5 rjkroege 2012-11-05 11:31:10 -0800 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? 869216 6 tdanderson 2013-04-04 10:15:20 -0700 Created a duplicate of this bug for Blink at crbug.com/226492. 1902200 7 ahmad.saleem792 2022-09-29 15:19:59 -0700 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! 1902235 8 ap 2022-09-29 17:59:45 -0700 A refactoring discussion from 2012 isn't really relevant today.