This is working now.

I spoke too soon, this is not working for me again. Definitely a intermittent problem.

agoode@, I cannot reproduce this on 50.0.2661.79 beta-channel or 52.0.2708.0 canary-channel on Chrome OS. Can you please do the following:

* Go to chrome://help and click "Check for and apply updates" to update to the latest version. Does it still reproduce after updating?

* Go to chrome://flags and switch the #top-chrome-md flag to "Non-material". Does it still reproduce?

#2, can you still see it on ToT or M-50 stable candidate?

This still happens to me with today's update:
Version 50.0.2661.91 beta (64-bit)
Platform 7978.66.0 (Official Build) beta-channel samus
Firmware Google_Samus.6300.174.0

This is with material enabled. Let me switch and try that.

"Non-material" still shows the incorrect behavior.

Thank you for providing more feedback. Adding requester "varkha@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I still cannot reproduce this on the latest beta version (50.0.2661.91). I tried various speeds, using an external mouse vs touchpad, and all of material, material-hybrid, and non-material. The scrubbing behaviour works fine for me in all cases.

So it is working for me on my chromebox that I just turned on after 2 weeks.

Version 49.0.2623.112 (64-bit)
Platform 7834.70.0 (Official Build) stable-channel panther
Firmware Google_Panther.4920.24.26

I'm going to switch to beta and see what happens.

Beta channel on chromebox is fine. Pixel is still broken. Same accounts on both.

OK:
Version 50.0.2661.91 beta (64-bit)
Platform 7978.66.0 (Official Build) beta-channel panther
Firmware Google_Panther.4920.24.26


BAD:
Version 50.0.2661.91 beta (64-bit)
Platform 7978.66.0 (Official Build) beta-channel samus
Firmware Google_Samus.6300.174.0

My current guess is that this is broken on touchscreen-enabled devices. It works fine on gnawty.

On 50.0.2661.91 beta-channel clapper (which is also a touchscreen device) this does not reproduce, so I don't think the presence of a touchscreen is to blame.

Another possibility could be the difference in device scale factor (samus and link both have a 2x device scale factor). However, I tried this on the latest beta version 51.0.2704.29 on link and cannot reproduce there. Valery, have you tried this on a samus (I don't have one)?

agoode@, please let us know on the bug if you still see this issue on samus when your beta version updates from 50 to 51.

Still broken on samus.

Version 51.0.2704.29 beta (64-bit)
Platform 8172.16.0 (Official Build) beta-channel samus
Firmware Google_Samus.6300.174.0

Same build as #14 works for me (also on samus). agoode@, do you have any other flag on that might be changing this?

The only flag I have set (and this is consistent across all devices) is to disable smooth scrolling.


This configuration also does not work:

Version 51.0.2704.29 dev
Platform 8172.16.0 (Official Build) dev-channel veyron_minnie
Firmware Google_Veyron_Minnie.6588.171.0

This is a touch screen device, with window.devicePixelRatio = 1.

I am investigating a bit under the assumption it has something to do with touch-enabled chromebooks.

ui/views/controls/menu/menu_controller.cc and ui/views/controls/button/menu_button.cc have some tricky code that might be suspect. I wonder if an extra PressedLock is being taken in some situations.

It's probably something in MenuController::ShowSiblingMenu.

This might be fixed now! I just had to cycle through dev mode and back to verified, and now it seems to work. It might just be working now since the latest update on May 13.

Version 52.0.2727.0 dev
Platform 8302.0.0 (Official Build) dev-channel veyron_minnie
Firmware Google_Veyron_Minnie.6588.171.0

I will comment here if the problem comes back on Minnie or if the problem gets resolved on the Pixel 2.

Ok, I figured it out. It works only when Projection Touch HUD is off (ctrl-alt-p).

I usually leave it on to see the touch points, and this breaks scrubbing. When I wiped the computer, it reset to off and it briefly worked.

+Kinross who might know about connection of this to touchview.

Removing MD label and Pri-3 since this is restricted to Projection Touch HUD.

This is now broken with or without Projection Touch HUD turned on.

Version 53.0.2785.4 dev
Platform 8530.6.0 (Official Build) dev-channel veyron_minnie
ARC Version 3026157
Firmware Google_Veyron_Minnie.6588.197.0

On Kevin, this is reproducible regardless regardless of the Projection Touch HUD.

I tried on both kevin and peach_pit with the exact same build; repros on kevin, doesn't repro on peach_pit. Could be related to devices with touch screens.

The reason is display::Screen::GetScreen()->IsWindowUnderCursor() always returns false on kevin [1]

Further investigation, I found that
root_window->GetTopWindowContainingPoint() [2] returns a window named "ExoShellSurface" rather than the window of the owner widget of the menu controller!

+oshima, +jamescook: What is that ExoShellSurface and why does it show up only on kevin and not peach_pit?

A suggested simple fix is at: https://codereview.chromium.org/2715513006. But I'm not sure if that's the correct fix.

[1]: https://cs.chromium.org/chromium/src/ui/views/controls/menu/menu_controller.cc?type=cs&q=%22display::Screen::GetScreen()-%3EIsWindowUnderCursor%22+f:menu_controller.cc+package:%5Echromium$&l=1511

[2]: https://cs.chromium.org/chromium/src/ash/display/screen_ash.cc?type=cs&q=root_window-%3EGetTopWindowContainingPoint&l=107

+reveman
I believe ExoShellSurface is used for arc++ windows.

+sadrul@

Exo creates a transparent window that covers entire desktop, and that's what you're getting.

It has its own targeter, but looks like GetTopWindowContainingPoint isn't using the targeter but simply using the window's bounds.

My guess is that this predates the targeter framework, and was supposed to be migrated (in which case, your CL is correct). 

sadrul@ WDYT?

> Exo creates a transparent window that covers entire desktop, and that's
> what you're getting.

Note that this approach will not work with mus+ash. We need to find a good solution for this. It would be better if we do that without waiting for mus+ash to happen.

ExoShellSurface is the top level window for wayland clients. The bounds of this window matches the area of the client that should be considered for layout. If the client is providing it's own shadows then you can expect one of it's child windows to be larger than the ExoShellSurface window.

In the case of Arc++ where we currently use absolute positioning you'll find a child window that covers the whole screen but is completely transparent.

Could ExoShellSurface have been the cause when the bug was originally filed (a year ago) ?

Re#31

> > Exo creates a transparent window that covers entire desktop, and that's
> > what you're getting.
>
> Note that this approach will not work with mus+ash. We need to find a good
> solution for this. It would be better if we do that without waiting for 
> mus+ash to happen.

Sadrul, sorry, I'm a bit confused about what you're referring to by "this approach". Is it the proposed fix in the CL in #28? Or is it what you quoted above "Exo creates a transparent window that covers entire desktop"?

I am referring to exo creating a transparent window covering the entire desktop.

Re#35: Thanks! What about the proposed fix? Does it work?

Just curious. This doesn't have to be a window, but could simply be a layer because they do not have to receive events, nor the target. sadrul@, won't it stil work?

I do not know what the window is used for, so I can't tell ... although, if the window is not receiving events, and is transparent, why have it at all?

It's used as a container for layers created by android apps.

Oh ok, thanks! Then yeah, just making it a layer should be sufficient.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6ad1835ebdf60d5363f0df85437f34a4c3e46052

commit 6ad1835ebdf60d5363f0df85437f34a4c3e46052
Author: afakhry <afakhry@chromium.org>
Date: Fri Mar 31 02:08:55 2017

Fix showing the sibling menu on mouse move

Using GetTopWindowContainingPoint() was returning the ExoShellSurfce
in the case of ARC++ devices, which was different from the window of
the widget that owns the menu. This prevented showing the sibling menu
when the mouse moved and hovered over the neighboring menu button.

We decided to remove GetTopWindowContainingPoint() as it's not needed
anymore.

BUG= 594439 

Review-Url: https://codereview.chromium.org/2715513006
Cr-Commit-Position: refs/heads/master@{#460995}

[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ash/display/screen_ash.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ash/drag_drop/drag_drop_controller_unittest.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ash/mus/screen_mus.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/extensions/shell/browser/shell_screen.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ui/aura/test/test_screen.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ui/aura/window.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ui/aura/window.h
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ui/aura/window_unittest.cc
[modify] https://crrev.com/6ad1835ebdf60d5363f0df85437f34a4c3e46052/ui/views/mus/mus_client.cc

Chrome OS 9532.0.0, 60.0.3092.0