Created attachment 536747 [details] [diff] [review] WIP v1 Mobile browser typically need to support a special mode to allow text in web content to be selected and copied to the clipboard. We are going to implement the Android model for this behavior. It will be available in all Fennec builds, not just Android. Attaching a WIP
Created attachment 537389 [details] [diff] [review] WIP v2 This patch positions the handles better on initial long tap (except when the web content is zoomed!) The handles are hard to "hit" on devices. We need to enlarge the hit area of the handles somehow (CSS padding or mouse tap "gravity")
Created attachment 540528 [details] [diff] [review] WIP v3 This patch works OK unless you double tap (or pinch zoom). Then the mouse coords seem wrong, but I haven't figured out why. Another problem with this patch is moving the start handle or a link will activate the link. Doing "mousedown" / "mouseup" on a link will do that. Should be simple enough to trick gecko into not making a "click". Last problem is making the handles go away when page changes or resets in some way. Again, easy enough to listen for the right events (like Form Helper). I really need to figure out the offset/scale/ coord problems before moving on.
Note: To test, load a page with <p> text, like planet mozilla. * Try long tap on text with no scrolling or changes in zoom. (should be fine) * Scroll down the page and try again. (should be fine) * Double tap or pinch to zoom in and try again. (handles are mis-positioned) Do the zoom test with no scroll to actually get a chance to see the handles mis-positioned. Otherwise they are off-screen.
Created attachment 541169 [details] [diff] [review] patch With help from Wes, this patch seems to work pretty well. Well enough to get reviewed.
Some notes from testing this patch: If I drag a handle over a link, I trigger the link when I release my mouse/finger. Zooming with the scroll wheel (rocker switch on Maemo) leaves the text selected but does not adjust the handle positions. This doesn't matter on Android currently, but we should probably listen for zoom events and either cancel the selection or move the handles. Once in a while I get in a state where one the end handle is correctly positioned, but the start handle is offset vertically. It's drawn too far down by a fixed number of pixels. The offset remains the same size regardless of what text I select or where I zoom/scroll.
(In reply to comment #6) > Some notes from testing this patch: > > If I drag a handle over a link, I trigger the link when I release my > mouse/finger. Fixed using a hack: Don't fire a mouseup, only a mousedown. That is enough to position the caret. A platform fix would be better. I'll file a bug. > Zooming with the scroll wheel (rocker switch on Maemo) leaves the text > selected but does not adjust the handle positions. This doesn't matter on > Android currently, but we should probably listen for zoom events and either > cancel the selection or move the handles. Fixed. Added a few events to hide the handles > Once in a while I get in a state where one the end handle is correctly > positioned, but the start handle is offset vertically. It's drawn too far > down by a fixed number of pixels. The offset remains the same size > regardless of what text I select or where I zoom/scroll. Could be related to the link issue, which I "fixed" It seemed to work better for me on device with the fix. The platform fix is the best solution. I have found the selection to be slow to update at times too, especially during a page load. Again, passing mouse events/messages and using the mouse event hack are probably the cause. We'll see what a proper platform API does to improve the perf.
Created attachment 541468 [details] [diff] [review] patch final? This patch also adds the TapMove listener to the window, making it easier to drag the handles.
Comment on attachment 541468 [details] [diff] [review] patch final? Looks good to me. Might still cause some issues on sites with onmousedown handlers in content, but that can be fixed in the platform later. SelectionHelper could be moved to its own lazy-loaded JS file, if we want to prevent common-ui.js from growing too large.
http://hg.mozilla.org/mozilla-central/rev/dbd02a315176 Filed bug 666819 for platform API help
Created attachment 541575 [details] [diff] [review] patch for tests I broke a test, so this patch fixes it and adds a simple test for tapping in a block of text. The broken test was an <img> wrapped in a <div> and <div>s are fair game for text selection, so we got a "content-text" type being returned too. The fix was to add that to the expected types check. I also added a plain text tap check too. It should only return "content-text"
backed out to investigate why after this changeset we didn't see anymore a green b-c on Android. http://hg.mozilla.org/mozilla-central/rev/a87ee7550f6a
Created attachment 541724 [details] [diff] [review] simple patch to fix browser_tapping.js failing test without crashing the browser feel free to use this patch. Tested on a tegra and it passes the browser_tapping.js testcase
Created attachment 541757 [details] [diff] [review] patch with bustage fixed This patch is the same basic patch as before. It has a little more error handling and Joel's simple fix for the failing test. I'll post an interdiff in a moment
pushed again: http://hg.mozilla.org/mozilla-central/rev/99708970cdf5
Verified Fixed based on current implementation Mozilla/5.0 (Android; Linux armv7l; rv:7.0a1) Gecko/20110630 Firefox/7.0a1 Fennec/7.0a1
Litmus manual: https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=22927 https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=22928 https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=22929