New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 765266 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Context Menu > Paste not treated as a user-gesture

Project Member Reported by elawrence@chromium.org, Sep 14 2017

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."


 
Blocking: -764760
Labels: Hotlist-Input-Dev
Owner: dtapu...@chromium.org
Status: Started (was: Untriaged)

Comment 3 by rbyers@chromium.org, Sep 25 2017

Cc: -dtapu...@chromium.org a...@chromium.org mustaq@chromium.org
I suspect this is a recent regression. cc avi who may know details.

Comment 4 by rbyers@chromium.org, 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.
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.

Comment 6 by a...@chromium.org, Sep 25 2017

My user gesture change was reverted and merged. I don't believe that is it.

Comment 7 by mustaq@chromium.org, 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?
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.
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
Cc: rbyers@chromium.org
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")


Project Member

Comment 11 by bugdroid1@chromium.org, 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

Status: Fixed (was: Started)
Cc: rnimmagadda@chromium.org dtapu...@chromium.org
 Issue 552975  has been merged into this issue.

Sign in to add a comment