[Webkit-unassigned] [Bug 105189] Add function to move caret selection towards a point

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Dec 18 07:37:19 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=105189





--- Comment #6 from Chris Hopman <cjhopman at chromium.org>  2012-12-18 07:39:35 PST ---
Sure. On Android, in an editable area, you can have an insertion handle. The user can drag this around to move where the caret selection is in the editable area. When those movements are within the editable area, the expected behavior is simple, move the caret to where its dragged. When a user drags the insertion handle outside of the editable area, the expected behavior is that the caret stays inside the editable area and vertically/horizontally aligned with the event position (unlike, for example, a range selection), and the edit box should scroll (slowly) towards the event position. Other touch-based(/touch-supporting) platforms would also likely want similar behavior.

When I originally wrote this, I tried to decompose it into:
1. Move the selection to the closest horizontal/vertically aligned position in the visible editable area.
2. If needed, move the selection 1 more line/character towards the point (i.e. scroll one line/character).
I did not find either of those behaviors already available, and that direction didn't work out as well as the way in this patch (quite possibly due to my inexperience in WebKit).

That being said, any suggestions for better approaches would be appreciated.

https://codereview.chromium.org/11593011/ is a chromium change that uses this new function. (Though that change is rather trivial other than the tests).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list