Closed Bug 668201 Opened 8 years ago Closed 8 years ago
Provide more intuitive method to select text (one that's not as open to accidental text selection)
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.
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).
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.
Depends on: 661388
the point of the handles being below the text is so you can drag them while still seeing what you're selecting
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)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(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.
Anna, just a note. Normally, only the owner (developer) of a certain feature/bugzilla component is allowed to resolve->WONTFIX a bug.
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.
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.
Summary: Copy Text Review → Review of process in which text is copied to prevent accidental text selection offering up alternative method to prevent accidental text selection
Summary: Review of process in which text is copied to prevent accidental text selection offering up alternative method to prevent accidental text selection → Provide more intuitive method to select text (one that's not as open to accidental text selection)
You need to log in before you can comment on or make changes to this bug.