sap.m.Button: "Sticky Hover" on Combi/Hybrid devices

[wridgeu]

OpenUI5 version:

Any (tested the behavior from 1.71.XX to 1.120.XX in UI5 samples, same result anywhere)

Browser/version (+device/version):

• Browser Version: Chrome 120.0.6099.129 (Official Build) (64-bit)
• Device: any combi/hybrid device (I assume; regular touch seemed fine); It will always happen during device emulation in chrome using e.g. "Nest Hub Max"
• Concrete Monitor in use (thin client setup with regular windows) used in real life scenario is: iiyama PL TF2234MC-B7X Touch Display

URL (minimal example if possible):

Simply use the UI5 samples: https://sdk.openui5.org/entity/sap.m.Button/ (any version will do, we currently still use 1.71.XX, below gifs are done using latest 1.120.XX).

Make sure you're using/simulating a combi device (see steps to reproduce below).

Steps to reproduce the problem:

1. Making use of any combi-device and using the touch functionality. Using device emulation in chrome with e.g. "Nest Hub Max".
2. It sometimes happens for regular taps/touches but to provoke it more obviously: click & drag outside the button. This simulates a user touching the button for a prolonged time, sometimes maybe on the edge of the button or maybe slightly swiping by accident.
3. Observe the button state becoming :hover'ed resulting in a sticky hover as no real hover took place.
4. The :hover classes are removed again only upon further interaction with the application (clicking/touching the screen again anywhere).

The following gif shows the problem, though in the latest versions less visible due to the subtle change in the color palette. Take a close look on the buttons when the touch point is dragged below them and clicked again.

For better visibility, here again in dark mode:

Getting this ghosting/sticky :hover effect results in users being confused from time to time for multiple reasons.

1. This interactions doesn't (or not always) trigger the actual press of the button, which is correct but
2. because of the visual feedback there is confusion now whether the button was pressed or not and if it can be pressed again

What is the expected result?

It is a hard problem to "solve" I think. The best case scenario would be to either disallow :hover taking place or trying to resolve the issue by (maybe) adding on to the pre-existing touchend detection here which does not exist in older UI5 versions though.

What happens instead?

The button stays :hovered which, depending on the UI5 version and theme used, can look very confusing.

Any other information? (attach screenshot if possible)

some more context

Note also that the gifs show an over exaggerated way to trigger the behavior. In our actual case the users simply pressed the button and sometimes it ended up like this because of how they swiped across the button or maybe they pressed too long. A bit more context: The touchscreens are being used within a warehouse.

MDN note about :hover

:hover is already known to be tricky for touch devices, citing MDN

Note: The :hover pseudo-class is problematic on touchscreens. Depending on the browser, the :hover pseudo-class might never match, match only for a moment after touching an element, or continue to match even after the user has stopped touching and until the user touches another element. Web developers should make sure that content is accessible on devices with limited or non-existent hovering capabilities.

what else did I try?

I did try to simply manually overwriting the css of the demokit trying out a few things. Of course one cannot simply do that in the actual source code of UI5 as there are way more devices, conditions and what not affected but what seemed to work was adding media queries allowing the hover to only take place when "real touch" is supported (if I understood it right ^^).

Here the result (only added for the Accept button, Reject is the counter-example)

side note

I acknowledge this might not be worth fixing and is a rather annoying problem to have. I'm not sure if it was considered taking care of it or if it is a known issue but I wanted to bring this to the teams attention anyway, maybe something can be done about it.

The way we went ahead to have a quick fix was manually overwriting the :hover styles with the same style of a not-hovered button. This way we lose some visual feedback for the user, some indication of the button being pressed/touched. But we somewhat made up for it making use of a busy-indicator. Its not the best way to solve the issue but definitely the simplest for now.

BR, Marco

[Todor-ads]

Hello @wridgeu , Thank you for sharing this finding. I've created an internal incident DINC0028104. The status of the issue will be updated here in GitHub

Regards, Todor

[NHristov-sap]

Hi @wridgeu ,

I have inspected the reported issue and it seems it is reproducible even with pure HTML (see https://jsbin.com/ximumaleva/2/edit?html,output). It happens on Chrome and Edge only, and it seems it is a browser issue. We will register it in Chromium bug board.

Best Regards, Nikolay Hristov

[wridgeu]

Hey @NHristov-sap,

nice find! Sorry that I did not test that. Will the bug report id (or similar) be linked here as well?

Thank you!

Br, Marco

[NHristov-sap]

Hi again,

here is the issue opened in Chromium bug board: https://issues.chromium.org/issues/330213583

BR, Nikolay Hristov