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

[bugzilla-daemon at webkit.org]

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





--- Comment #23 from Chris Hopman <cjhopman at chromium.org>  2013-01-02 16:49:53 PST ---
(In reply to comment #18)
> (In reply to comment #14)
> > (In reply to comment #13)
> > Chromium draws them. I would be happy to reuse existing behavior, but I was unable to find it. For selection handles (i.e. range selections) we are using the behavior of extending selections (like dragging with a mouse). The insertion handle moves a caret selection and I could not find any such existing behavior.
> 
> I suspect this is the core confusion.  For other ports, WebKit itself draws all the input UI, like the cursor, etc.  In this case, Chromium is drawing it's own selection UI (in addition to WebKits) and thus needs a hook to tell WebKit to update it's part of things.   As Ryosuke points out, if this were in WebKit, most of the code would just be in EventHandler.cpp (the drawing code likely in RenderThemeChromiumAndroid?).
> 
> I'm not sure this patch is wrong.  Just slightly atypical for WebKit's previous editing design.
> 
> Again, rniwa has been in this code much more recently than I, so I can correct any errors I may have made above. :)

Looking through the history of these functions... a WebFrame::moveCaret() function used to exist. It was merged into selectRange with https://bugs.webkit.org/show_bug.cgi?id=96508. Since selectRange is not the same behavior as moveCaret (I have a local patch that extends selectRange to support the moveCaret behavior, but it is not any simpler than this patch), and there is precedent for such a moveCaret hook, I think this approach should be fine (though I do prefer the ::moveCaret() function name to the name in my last patch).

eseidel, rniwa: What do you think?

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