Browser-laptop: Tab hover gets stuck when opening a new tab (no mouseevents over webview)

[srirambv]

Description

Sometimes tab hover gets stuck when opening a new tab

Steps to Reproduce

Possible steps but not sure about it

1. Clean install 0.21.654
2. Open a couple of tabs and load sites
3. Open a new tab via keyboard shortcut and visit a site, drag mouse cursor down via other tabs, tab hover gets stuck for one of the previously opened tabs

Actual result:
Sometimes tab hover gets stuck when opening a new tab

Expected result:
Shouldn't hover over tabs until the time spent on tab is satisfied

Reproduces how often:
Sometimes can't really put a number on it

Brave Version

about:brave info:

Brave | 0.21.654
-- | --
V8 | 6.5.254.26
rev | bc6272c
Muon | 5.1.3
OS Release | 10.0.16299
Update Channel | Beta
OS Architecture | x64
OS Platform | Microsoft Windows
Node.js | 7.9.0
Brave Sync | v1.4.2
libchromiumcontent | 65.0.3325.88

Reproducible on current live release:
No

Additional Information

Could be due to the fact that on hover able to click elements of a page could be the root cause

[bsclifton]

Was easily able to repro- basically, the preview is stuck after you move mouse off of tab

Let's retry this once a new build comes out (which removes changes other than Chromium 65)

[srirambv]

Still seeing this issue on the C65 build 0.21.656

[kjozwiak]

Added the release/blocking tag as we should fix this in this milestone. Even though this isn't a serious issue, it's annoying and breaks past functionality. We'll be updating users to a worse experience if this isn't addressed.

[srirambv]

This is an annoying bug. Have to disable tab preview to use. Definitely blocking the release.

[petemill]

Looks like it's to do with the <webview>, maybe something changed with that in C65. The webview is directly below the tab, and when the mouse moves down from the tab to the webview, the tab is not getting the mouseleave event. Simply making the webview visibility: hidden restores the correct mouseleave event on the tab. Conversely, the <div class='mainContainer'> element which contains the <webview> does not receive a mouseenter event even though it should. Seems like the webview plugin is not passing mouse events to the containing WebContents.

[cezaraugusto]

@petemill did you tried on Windows? Wouldn't be surprised if this is somehow related to -webkit-app-region

[cezaraugusto]

btw you can see it same way Pete described by just watching the close tab icon not fading away when you hover over tab then back to webview

[petemill]

Reproducible 100% of the time on Mac and Windows when moving mouse down from tab element to content area. app-region value of source element container has no effect. Hiding webview via css 'fixes' issue.

[petemill]

I managed to mostly replicate the mouse events issue with C64 muon by commenting out the line owner_view->ProcessMouseEvent(*event, latency_info); in RenderWidgetHostInputEventRouter::RouteMouseEvent which stops mouse event from being sent to containing view (i.e. the window view).

And looks like that entire method has been refactored to a new render_widget_targeter.cc. Perhaps that's the origin of the issue we're seeing?

[bsclifton]

Fixed with https://github.com/brave/muon/commit/bf26683a1a96c24e8025a8328c0b291b51aa7094

Stay tuned for a new build... (will be Muon 4.9.2)

[kjozwiak]

Also ensured that the Tab Preview Delay settings under about:preferences#tabs are working as expected.