Closed Bug 1300723 Opened 8 years ago Closed 1 year ago

Improvements to text selection on touch devices

Categories

(Core :: DOM: Selection, enhancement, P5)

51 Branch
Unspecified
Windows 10
enhancement

Tracking

()

RESOLVED FIXED
Tracking Status
firefox51 --- affected

People

(Reporter: phlsa, Unassigned)

References

Details

There are a couple of issues with text selection on Windows touch devices in the current Nightly. This obviously needs some breakdown... * In editable text fields, don't show the touch handles unless the user is interacting using touch capabilities * For selecting text, mimic the behavior of Edge: - A single tap selects (and deselects) a word - Long-press triggers the context menu - In editable text fields, single-tapping alternates between selecting the tapped word and setting the cursor position
This is all Core/Gecko behaviour, not a Firefox UI one. So I'm not sure it makes sense to have it be part of the fx-qx work. Are any of these issues serious enough to block shipping this? It feels like just the first one, potentially, and not the others?
Component: General → Selection
Flags: needinfo?(philipp)
Product: Firefox → Core
I also think that the first point might already be filed as bug 1293483.
Blocks: 1195722
(In reply to :Gijs Kruitbosch from comment #1) > Are any of these issues serious enough to block shipping this? It feels like > just the first one, potentially, and not the others? Yes, the first issue is a regression, the others are enhancements.
Flags: needinfo?(philipp)
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #3) > (In reply to :Gijs Kruitbosch from comment #1) > > Are any of these issues serious enough to block shipping this? It feels like > > just the first one, potentially, and not the others? > > Yes, the first issue is a regression, the others are enhancements. The first point was in fact filed as bug 1293483 which we just closed as wontfix because nobody (in that bug) disliked having the handles show up, and a couple of people (including myself) liked having the handles. It's not clear to me what we gain by hiding the handles, but it's pretty clear what we lose - the ability to seamlessly switch from mouse to touch when adjusting a selection. The other things from comment 0 all seem reasonable enough.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4) > (In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from > comment #3) > > (In reply to :Gijs Kruitbosch from comment #1) > > > Are any of these issues serious enough to block shipping this? It feels like > > > just the first one, potentially, and not the others? > > > > Yes, the first issue is a regression, the others are enhancements. > > The first point was in fact filed as bug 1293483 which we just closed as > wontfix because nobody (in that bug) disliked having the handles show up, > and a couple of people (including myself) liked having the handles. > > It's not clear to me what we gain by hiding the handles, but it's pretty > clear what we lose - the ability to seamlessly switch from mouse to touch > when adjusting a selection. > > The other things from comment 0 all seem reasonable enough. I just commented on that bug. By showing the handles, we are changing behavior on a frequent action (text selection when using a mouse) AND deviating from the platform standard. Look at how Edge implements this. They don't show handles when selecting with the mouse but do so once the user touches the selection with their finger. This approach creates a lot less friction in the experience.
Severity: normal → enhancement

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.