hover in v4 relies on a feature that is buggy in Chromium-based browsers

[ailon]

There's a long-standing bug in Chromium that incorrectly identifies 2-in-1 Windows PCs with external keyboard and mouse attached as having no "fine" inputs. Looks like Tailwind CSS 4 now relies on this "feature" which makes hover (and possibly other things) not work on projects using v4 on these PCs.

Here's the issue on the Chromium issues tracker:
https://issues.chromium.org/issues/40277167

I'm attaching a video demonstrating this in action.

20250214_082629.mp4

[ailon]

Looks like the v133 of Chrome mentioned here doesn't fix this issue in the 2-in-1 scenario.

[philipp-spiess]

@ailon Hey! Can you try if any of the approaches from the playground work for you? https://play.tailwindcss.com/36UPgr54ER?file=css

[ailon]

Without the physical keyboard attached only the first one works. With the keyboard attached - all work.

[philipp-spiess]

@ailon Can you paste your full Chrome version number? Just to be certain you have the hotfix patch that resolves the hover issues.

[ailon]

Chrome version: 133.0.6943.99
Same behavior in Edge 133.0.3065.59

[philipp-spiess]

Thanks! Sorry for the questions we just got a bunch of similar issues and I wanted to be certain this is unrelated to the Chrome bug and really needed to get some data from the playground I created for someone who was having the issues with Windows in tablet mode.

Really unfortunate that none of these media queries trigger in this setups. Is there any way to disable tablet mode with in this case since you do have an external keyboard and mouse it seems?

The way we think about :hover though is that it's more of a progressive enhancement in general since mobile devices don't support hover anyways, so UIs should be built with that limitation in place and not work without it anyways. That's why we made the change to only show it on devices supporting hover so that it doesn't lead to the weird "tap-to-see-hover-styles" experience on mobile devices.

Agree that this might break a bunch of sites though but I wonder if that will be better long-term since it forces Chrome to fix the issues and report capabilities correctly.

[ailon]

Thank you for looking into this @philipp-spiess!

As someone mentioned on the other thread, there seem to be two [somewhat] unrelated Chromium issues. The one that was seemingly fixed and was a recent one (if I understand it correctly) and this one that I linked in the first post in this thread that has been there for many years.

I would hope that Tailwind is big enough of a deal for them to reprioritize this bug but I'm not holding my breath. This bug has been affecting Spotify's desktop client as well as many other Chromium/Electron based apps (eg. Linear) for years and it's still there.

It also doesn't seem to be Windows' (Microsoft's) fault as Windows is not in tablet mode in my setup with a full external keyboard and mouse attached. IIRC I confirmed that in real native Windows app setup back when I first identified this issue with Chromium. And it works correctly in Firefox on the same machine, so clearly something funky is going on the Chromium side.

I understand your motivation behind this but maybe since v4 is brand new it would be still possible to revert the default to the old behavior ala @custom-variant default-hover (&:hover); and have the new one as a custom variant? Otherwise, half the internet will be broken for people like me in a matter of months :)

[sousounibajis]

Even though I’m not in tablet mode, when my device is in tent mode the hover styles don’t apply. After reviewing the issue mentioned here, it seems there are two issues at play as @ailon mentioned: one related to touch input detection and another triggered by the device being flipped. From the discussion, one effective workaround is to override the default Tailwind behavior by adding: @custom-variant hover (&:hover) in turn allowing the hover styles to apply without checking for a “fine” pointer, and keeping the existing codebase intact (i.e., can continue using hover: as usual).

Additionally, some users mentioned that upgrading to Chrome 133.0.6943.99 fixes the issue in Chrome (though not in Edge), but that did not resolve it for me until applying the custom-variant hover.

[duprayae179dpl]

I'm following up to confirm that this is the exact issue that I'm having with my Dell XPS 2-in-1 laptop that I originally posted about in issue #16416 . If I flip my keyboard out, the hover effects work. When I flip the keyboard back, my laptop goes into "tablet mode" (which disables the integrated trackpad and keyboard) and the hover effects no longer work, even with an external mouse and keyboard connected.

Please note that this happens in all web browsers for me: Chrome, Edge and Firefox. It seems that it's the operating system (Windows) that's telling all web browser's what type of functionality is available to them. Again, if I flip the integrated keyboard outward, hover events work in all web browsers.

This issue is not related to the recent Chrome fix in version 133.0.6943.99 as it's still happening for me with this version. @ailon This seems to really be an edge-case with 2-in-1 laptops in Windows. Is anyone able to test this running a Linux OS?

[ailon]

@duprayae179dpl are you sure it happens to you in Firefox? I've tested it years ago when I first discovered this Chromium issue and also tested yesterday, and it was working fine. As do all the other really native Windows apps. On a different computer now, so I can't retest.

I think Chromium just takes a shortcut in determining values for all these pointer media queries based on the primary pointer when according to the spec for all the any-... queries it should check if any of the available pointers is fine.

The any-pointer CSS media feature tests whether the user has any pointing device (such as a mouse), and if so, how accurate it is.
...
fine
At least one input mechanism includes an accurate pointing device.

...

The any-hover feature is specified as a keyword value chosen from the list below.
...
hover
One or more available input mechanisms can conveniently hover over elements.

In any case, I'd hope Tailwind relying on this feature would prompt the Chromium team to prioritize fixing this, but I'm not holding my breath, unfortunately. If the Tailwind team decides to keep it as-is we are likely looking at getting rid of our computers in a few months as the web becomes broken(ish). 🥹

[sousounibajis]

It appears the root issue isn’t solely limited to Chromium but is tied to how Windows (especially in certain “tent mode” configurations) reports the pointer capabilities. When a 2‑in‑1 laptop is flipped into tent mode (even when an external keyboard and mouse are attached), the OS may signal that the primary pointer isn’t fine/ not precise, causing Tailwind’s v4 built‑in hover variant (which wraps all hover styles in a media query using (hover: hover)) to fail. This isn’t just a Chromium bug; in my testing I can confirm even Firefox ends up not triggering hover when in tent mode. So it confirms that the underlying issue isn’t just with Chromium. The operating system’s pointer detection in tent mode is the culprit. Although this isn’t ideal, using the custom variant override is the only non‑invasive fix that has worked, at least until a broader solution (either in OS reporting or Tailwind’s media query strategy) is available.

[ailon]

I've retested in Firefox and it works like it should any-hover:hover works fine as it should in this mode:

Whereas in Chrome (and everything Chromium) it doesn't:

I suspect @duprayae179dpl looked at the other two (hover:hover and pointer:fine) and those don't work on either as, afaik, they are meant to behave by the spec. The primary pointer in tablet mode is not "fine", but there are "fine" pointers available - hence any-pointer:fine should be true.

I think writing it off on Windows, as @sousounibajis suggests, is counterproductive as it removes the impetus from the Chromium team to address this. Clearly if it works as expected in Firefox, it's not a Windows issue. At the very least not an unsolvable obstacle on the browser level.

Also, for the sake of checking what works and what doesn't, I think it's better to use a more "pure" test here. Here are the results for Chrome vs. Firefox in tent/tablet mode:

[ottsch]

any-hover is also the only one the works for me in Firefox on a Windows laptop with touch display, using a mouse on an external monitor

[twinters]

Can confirm this is not a Chromium-related bug and new in v4.

Both in Firefox and Chrome, the hover prefixed classes only works if my detachable keyboard is attached (Microsoft Surface Pro 11), even while hovering using an external mouse.

It's also new in Tailwind v4 compared to v3, as the hover doesn't work on the v4 version over the hover example on these computers, but does work on the v3 version.

[jmlacroix]

We've been having issues with Tailwind v4 hover when running headless automated specs over GitHub actions (ubuntu22-full-x64) via Selenium / Capybara / Chromedriver. We couldn't trigger some hover actions and had to revert back to the old behavior by using the @custom-variant from the docs.