The feature to modify a value by dragging the mouse horizontally introduced in bug 1731734 is extremely sensitive. A one pixel movement after the mousedown event already enables it.

This is an issue if you actually want to open the inline editor to edit the value.

See also https://discourse.mozilla.org/t/how-to-disable-style-editor-horizontal-drag-to-amend-the-value/95814.

To improve the UX, I suggest to add a little threshold like 2 to 5 pixels to the mouse movement before the feature is activated. That avoids accidentally changing the value.

Sebastian

The severity field is not set for this bug.
:jdescottes, could you have a look please?

For more information, please visit auto_nag documentation.

P3 S3. I agree the feature is too sensitive, but given we allow users to disable it, there is already a workaround.

I tried to implement a quick deadzone of 5 pixels. It works nicely but I wonder if we should also add a "time-based" deadzone, only start updating the value if the user has been dragging for more than N milliseconds. We want to avoid updating the value whenever the user actually meant to click and not to drag. And playing with the feature, even with a 5 pixels deadzone, I can still trigger an update for a "heavy" click.

Or maybe the deadzone should be the whole bounding rect of the text we are updating? Usually when users click on a value it's in order to trigger the editor. So if the mouse leaves the boundind rect, it's a good indication that the user is really dragging and not clicking.

We can of course keep this bug to implement the basic pixel based deadzone and work on other improvements in follow up bugs.

Test needs more work, the fact that the deadzone drag triggers editors to open makes it a bit flaky.

(In reply to Julian Descottes [:jdescottes] from comment #2)

I agree the feature is too sensitive, but given we allow users to disable it, there is already a workaround.

Yes, that's a workaround, but not for the people that actually do want to use that feature. 😊

I tried to implement a quick deadzone of 5 pixels. It works nicely but I wonder if we should also add a "time-based" deadzone, only start updating the value if the user has been dragging for more than N milliseconds. We want to avoid updating the value whenever the user actually meant to click and not to drag. And playing with the feature, even with a 5 pixels deadzone, I can still trigger an update for a "heavy" click.

An additional time-based deadzone sounds intuitive to me.

Or maybe the deadzone should be the whole bounding rect of the text we are updating? Usually when users click on a value it's in order to trigger the editor. So if the mouse leaves the boundind rect, it's a good indication that the user is really dragging and not clicking.

The whole bounding rect might be too much in case of bigger numbers.

But for a good UX I'd need to try both out.

It wasn't explicitly mentioned before but this is also an accessibility issue for people with shaky hands. So the 5 pixels deadzone is already a good first step to mitigate this issue. So, thanks for that! I'll file a new bug for improving it including the ideas mentioned here.

Sebastian

https://hg.mozilla.org/mozilla-central/rev/2abf9db63de6

I managed to reproduce this issue on a 2022-04-11 Nightly build on macOS 11. Verified as fixed on Firefox 102.0b6(20220609185805) and Nightly 103.0a1(20220609220048) on macOS 11, Ubuntu 20.04, Windows 10 x64.