New issue
Advanced search Search tips

Issue 686906 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Oct 4
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Right-clicking on empty area of shelf breaks subsequent right click events on shelf icons

Reported by clshortf...@gmail.com, Jan 30 2017

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8872.76.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.105 Safari/537.36
Platform: 8872.76.0 (Official Build) stable-channel zako

Steps to reproduce the problem:
1. Right click on Chrome Tab

Secondary options (New Window, New Tab, etc) and default options should appear

2. Right click on empty shelf area

Default options appear

3. Right click on Chrome Tab again 

No secondary options appear

What is the expected behavior?
Secondary options should appear always on right click

What went wrong?
I'm assuming there's a flag or something that isn't properly handled when the empty shelf area right-click window closes

Did this work before? N/A 

Chrome version: 55.0.2883.105  Channel: stable
OS Version: 8872.76.0
Flash Version: Shockwave Flash 24.0 r0

 
Per triage: I can't seem to repro this with: 

Version 56.0.2924.79 beta (64-bit)
Platform 9000.76.0 (Official Build) beta-channel samus
ARC Version 3674649
Firmware Google_Samus.6300.174.0

Can you please test again with 56 when you get a chance? Thanks!
Stays the same on v56 on the HP Chromebox (zako)


Also reproducible on my 

9202.7.0 (Official Build) dev-channel samus
Version 57.0.2987.11 (Official Build) dev (64-bit)

I right click Chrome icon, right click a black empty area, and right click Chrome icon again with no clicks in between.

I can also reproduce by right clicking on an empty area 5 times and then right clicking the Chrome icon. No "New Window" options appear.
Owner: zork@chromium.org
Status: Assigned (was: Unconfirmed)
I could repro it on multiple devices. 
<triage>zork@ could you have a look into this</triage>

Comment 5 by zork@chromium.org, Feb 8 2017

Owner: glevin@chromium.org

Comment 6 by zork@chromium.org, Feb 8 2017

Components: -UI UI>Shell>Shelf
Reproducing steps in a video 
test (6).webm
2.2 MB View Download

Comment 8 by glevin@chromium.org, Mar 21 2017

Status: Started (was: Assigned)
Thanks, Omri.  For clarification, then, "Chrome Tab" in the original description doesn't refer to a tab in the Chrome browser, but rather to the Chrome (or any other) app icon on the shelf.

Comment 9 by glevin@chromium.org, Mar 22 2017

Cc: jonr...@chromium.org
I'm still trying to hunt down the exact cause, but it seems to be somewhere in the widget/view mouse event handlers.  One clue I've found: the problem got worse after this CL: https://codereview.chromium.org/1953753002.  The basic bug is that a right-click on the empty shelf area will make a subsequent rclick on an app icon show the basic (non-app) context menu.

Before CL: A rclick on an app icon would only show the basic (wrong) menu when a correct app rclick was followed by a single empty shelf rclick.  Any other combination of rclicks would produce the full (correct) app menu.  See shelf_rclick_old.webm.

After CL: After an empty shelf rclick, all subsequent rclicks (on app or empty shelf) show only the basic shelf menu.  See shelf_rclick_new.webm.  A left-click on the shelf will reset this (note that in both videos, I'm only right-clicking on the shelf).
shelf_rclick_old.webm
5.8 MB View Download
shelf_rclick_new.webm
1.7 MB View Download
When an open menu is canceled by a click outside of its region. 

This is done via RepostEventImpl: https://cs.chromium.org/chromium/src/ui/views/controls/menu/menu_controller.cc?rcl=f7a8e76c2a53d147b214c67167661e7760d9d5f3&l=164

Event propagation should send this to the shelf. I would suspect that the incorrect view within the shelf is receiving the right-click, and that is triggering the basic menu.

I would recommend taking a look at how the shelf generates its MenuModel. I can't recall if it is done in one central location, or if each icon view also generates one.

The reposted event also has the coordinates of the click, so it should be possible to traces back from the menu model creation to figure out why that view was targeted.
Labels: Touch-Friendly-Launcher Touch-Friendly-Launcher-Triaged
Cc: newcomer@chromium.org
Status: WontFix (was: Started)
Does not repro on M71

Sign in to add a comment