Context Menu > Paste not treated as a user-gesture |
|||||
Issue description
Chrome Version: 63.3214
When the user pastes via the context menu (Right-click > 'Paste' or right-click > 'Paste as Plain Text') it is not treated as a user-gesture. E.g. if a handler is fired like ChromeClientImpl::DidChangeValueInTextField, WebUserGestureIndicator::IsProcessingUserGesture() returns false. This is problematic because it means it's hard for ChromeClientImpl to distinguish between user actions and an automated document.execCommand("InsertText") call.
What is the expected result? WebUserGestureIndicator::IsProcessingUserGesture() returns true as the user performed a gesture by invoking the context menu command.
DCheng said:
"I suspect that's because paste sends an IPC directly, and we never put a user gesture on the stack
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?rcl=d4f61dcd9971c25cb70fe292278957f353be4455&l=1965
It seems like it'd be reasonable to have a user gesture on the stack for this."
,
Sep 25 2017
,
Sep 25 2017
I suspect this is a recent regression. cc avi who may know details.
,
Sep 25 2017
If this was a regression we should probably figure out when it changed to see if we should consider merging the fix.
,
Sep 25 2017
FWIW, autofill_agent.cc leads me to think otherwise:
// Disregard text changes that aren't caused by user gestures or pastes. Note
// that pastes aren't necessarily user gestures because Blink's conception of
// user gestures is centered around creating new windows/tabs.
if (is_user_gesture_required_ && !IsUserGesture() &&
!render_frame()->IsPasting())
return;
Incidentally, the reason I originally filed this was because I needed to distinguish execCommand from a user-action. It turns out that there's a better way to do that, so I don't know whether any other codepaths really need/want this.
,
Sep 25 2017
My user gesture change was reverted and merged. I don't believe that is it.
,
Sep 25 2017
elawrence@: I believe this bug appears before your fix for Issue 764760 because the fix went in for 63.0.3217.0. Right? Or did you mean some other change?
,
Sep 25 2017
Re #7: I filed this Issue because I originally thought I might fix Issue 764760 by checking for a user-gesture. Ultimately, my fix for 764760 wasn't based on looking at gestures at all (because Document has a trivial way to check whether an execCommand is in progress, so I use that instead). This Issue ("Paste isn't treated as a User Gesture") remains literally valid, but I expect that it has behaved this way for a long time (as noted in comment #5) and thus I'm not sure whether or not this issue is something that needs to be addressed. It's not clear whether there is any web content that expects to e.g. be able to open a popup window if the user pastes text from the context menu.
,
Sep 25 2017
I don't think this is a recent regression. I tried a really old version and Chrome 28 has this behavior. Ctrl-V opens a new window. But clicking paste from the context menu doesn't. Here is an example: http://jsbin.com/fuficop/edit?html,js,output
,
Sep 26 2017
FWIW: Edge, allows Ctrl-V/Paste from the context menu to do user gestures (such as window.open/fullscreen) Firefox, allows Ctrl-V to do user gestures (fullscreen, window.open gets blocked), doesn't allow Paste via context menu to do this (reports "was not called from inside a short running user-generated event handler")
,
Oct 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/341da2d7312dd48c455389ac0d69dda21f81485a commit 341da2d7312dd48c455389ac0d69dda21f81485a Author: Dave Tapuska <dtapuska@chromium.org> Date: Mon Oct 02 15:51:48 2017 Allow ExecuteCommand to be a user gesture. ExecuteCommand actions delivered from the browser should be considered user gestures. BUG= 765266 Change-Id: I022940581c964f0b132ad285432902a3d9351325 Reviewed-on: https://chromium-review.googlesource.com/682599 Reviewed-by: Rick Byers <rbyers@chromium.org> Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Cr-Commit-Position: refs/heads/master@{#505626} [modify] https://crrev.com/341da2d7312dd48c455389ac0d69dda21f81485a/third_party/WebKit/Source/core/exported/WebFrameTest.cpp [modify] https://crrev.com/341da2d7312dd48c455389ac0d69dda21f81485a/third_party/WebKit/Source/core/frame/WebLocalFrameImpl.cpp
,
Oct 2 2017
,
Nov 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by elawrence@chromium.org
, Sep 15 2017