668201 - Provide more intuitive method to select text (one that's not as open to accidental text selection)

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Paul [pwd]]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110628 Firefox/7.0a1
Build ID: 20110628030753

Steps to reproduce:

Copying text from a page has recently been implemented in a manner where its invoked too easily and not accurate enough. We should reimplement it in a more user-friendly, phone-friendly manner being more dependent on gestures.



Actual results:

Hold your finger on a page and some seemingly random text is selected


Expected results:

A user should hold their finger on a page at which point a magnifying glass is presented to get the exact position the user wants to start the selection. A user should then use a second finger (while the first is still applied on the screen) to mark the end of the selection. At the point the second finger touches the screen, the magnifying glass should be on that touch point. When the first finger is released, the text should be copied to the clipboard.

Comment 1

[Aaron Train [:aaronmt]]

While it's not an iOS style magnifying glass, Android style text selection handles recently landed in bug 661388, that of which allow you to manipulate and select with accuracy (once the dependancy bugs are ironed out).

Comment 2

[Paul [pwd]]

I think the implementation of that bug is what's causing the usability issue based on timeline. While the markers are fine, they're below the finger which makes it hard to see there's a selection. Can we not make a magnifying glass by creating a frame with the section zoomed in at +100%. That way we're not relying on the native zoom? Also the single long tap is causing the issue with attempting to select links to open in the content. If we move to a multi-touch invocation (like that described above), we can avoid that.

Either way, we can at least move the markers to the top rather than below and thus hiding behind a finger/thumb.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

the point of the handles being below the text is so you can drag them while still seeing what you're selecting

Comment 4

[Anna (Waverley)]

I will mark this bug as RESOLVED WONTFIX, based on the fact that bug 661388 has landed and the text selection feature works fine.

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:8.0a1) Gecko/20110707 Firefox/8.0a1 Fennec/8.0a1 

Device: HTC Desire Z (Android 2.2)

Comment 5

[Paul [pwd]]

(In reply to comment #4)
> I will mark this bug as RESOLVED WONTFIX, based on the fact that bug 661388
> has landed and the text selection feature works fine.
> 
> Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:8.0a1) Gecko/20110707
> Firefox/8.0a1 Fennec/8.0a1 
> 
> Device: HTC Desire Z (Android 2.2)

This was filed on the back of bug 661388 being faulty hence the dependency. Don't get me wrong, I'm not against the WONTFIX, just saying that a bug designed to fix a bug that falls short in terms of usability is a little nonsensical.

Comment 6

[Martijn Wargers (dead)]

Anna, just a note. Normally, only the owner (developer) of a certain feature/bugzilla component is allowed to resolve->WONTFIX a bug.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

WONTFIX is fine for this bug.

If someone feels there are problems with a crrent implementation, they can always file a bug. "Copy Text Review" is not the best summary for such a bug though. Try to be more specific in the request. Also note that elaborate UX fixes are probably less likely to be implemented, especially in the short term. Try to break solutions down into smaller chunks of work, so we can actually get something landed.

Lastly, make sure to note the UX issues with the current impl and try to focus less (or secondarily) on the new solution. Getting the point across about what's hard or bad about the current feature is more important.

This bug seems like a dupe of bug670222 as well.

Comment 8

[Paul [pwd]]

I've fixed the title, hopefully in future I can refrain from such ambiguity in filing bugs.

Regarding suggestions of new implementations, I do try and limit them to completely new features or features that in my humblest of opinions don't do the job as best they can. The method suggested above, is actually the method used to picture selection/cropping on Android anyway. Had someone marked this as NEW and requested this be broken down to become a meta bug, I'd have happily filed dependencies breaking this down into smaller chunks.