No hover color for Menu List Items in Chrome 74

[matthias-ccri]

Hi folks, I'm seeing a slight issue in Chrome 74, reproducible on the Menu demo page. When I mouseover a menu list item with the cursor, there is no background color change for the hovered item. Also, the focused item turns white when hovered.

A screen capture shows it best:

Steps to Reproduce 🕹

Link: https://codesandbox.io/s/9204p0pxo4

1. Use Chrome Version 74.0.3729.131 (Official Build) (64-bit)
2. Open the Menu
3. Using the cursor, mouseover the menu list items

Your Environment 🌎

Tech	Version
Material-UI	latest
Browser	Chrome Version 74.0.3729.131 (Official Build) (64-bit)

[eps1lon]

Can't reproduce this with the same chrome build and Ubuntu 18.04.2 LTS. What OS are you using? Do you have the same issue in an incognito window or other browsers?

[matthias-ccri]

Hi @eps1lon that's super wierd. Here's more information:

• The problem is still present in incognito mode in Chrome.
• In Firefox it behaves as expected (Firefox Quantum 66.0.5 (64-bit))
• Chromium shows the issue in normal and incognito. Chromium version 73.0.3683.86.
• I'm using Ubuntu 16.04 LTS
• Graphics: Intel® Iris 6100 (Broadwell GT3)
• Display manager appears to be lightdm 1.18.3. (Ran systemctl status display-manager, lightdm --version)
• I'm running intel graphics of some sort

⚡ sudo lshw -c video
  *-display               
       description: VGA compatible controller
       product: Iris Graphics 6100
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:45 memory:a9000000-a9ffffff memory:b0000000-bfffffff ioport:3000(size=64)

I did notice — key interaction worked. The up and down arrows changed the focused item. That might be a hint. Does material-ui do some sort of black-magic detection of whether a user is keyboard-only?

[eps1lon]

I did notice — key interaction worked. The up and down arrows changed the focused item. That might be a hint. Does material-ui do some sort of black-magic detection of whether a user is keyboard-only?

hover and focus styles visually are different and their detection is implemented differently. Hover uses the css :hover pseudo selector while focus uses a focus-visible polyfill. Could you enable Experimental Web Platform features in chrome://flags and see if keyboard interactions change the style?

[matthias-ccri]

Yes, the keyboard interactions changed the style with the Experimental Web Platform features flag enabled, just the same as with it disabled.

[eps1lon]

Yes, the keyboard interactions changed the style with the Experimental Web Platform features flag enabled, just the same as with it disabled.

So it's likely not pseudo selectors per se. Just :hover isn't working. Could you include a screencast of the following interaction:

1. goto https://material-ui.com/demos/menus/#complementary-projects
2. Open menu
3. inspect focused item
4. toggle :hover in dev tools on the other item

[matthias-ccri]

Interesting -- there's a @media (hover: none) rule that's applying background-color: transparent.

[eps1lon]

Ah nice. Not sure why this media query triggers in your browser. Sounds like a bug in chrome.

@oliviertassinari Though I don't understand why we need this here. If the device isn't hover capable we don't need to reset the color, no? Change was added in #7692

[oliviertassinari]

If the device isn't hover capable we don't need to reset the color, no?

@eps1lon Mobile devices don't have a hover capability but simulate it, we need to counter the simulation. This media query shouldn't be triggered in this case. Can we ignore the problem?

[matthias-ccri]

Yeah it seems like a problem with my setup — Chrome plus my desktop environment plus who-the-hell-knows what customizations I made to it.

[eps1lon]

If the device isn't hover capable we don't need to reset the color, no?

[...] we need to counter the simulation.

Why? I'm sure I asked this before but it still didn't quite click for me.

[oliviertassinari]

I don't know why mobile browsers simulate the hover pseudo class. We shouldn't display the hover state after a touch interaction. It's a mobile web default behavior, not a mobile app one.

[eps1lon]

We shouldn't display the hover state after a touch interaction.

Ah that was it. Touch will leave to element in a hover state, right?

[oliviertassinari]

Yes, that's right. It's the essence of the problem.

[eps1lon]

Yeah got it. Probably will ask again in a couple of days, though. @matthiasdailey-ccri Guess we can close this?

[matthias-ccri]

Sure

[wyqydsyq]

So wait what is the solution here? I'm using Chrome 84 on Ubuntu (Wayland GNOME 3.28.4) and find that none of the MUI hover effects work in Chrome due to this media query being incorrectly applied. It might be caused by something weird in my environment, but there's no way of knowing whether it will also affect end-users.

[oliviertassinari]

So wait what is the solution here?

To fix your environment? We haven't seen a lot of people in this case so far. We have seen the opposite problem too, where Samsung phones consider they have the hover capability available, which lead to residual hover effect after tap on buttons.