[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 #21 from Chris Hopman <cjhopman at chromium.org>  2012-12-19 15:03:49 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?).
> 
Yes this is adding a hook similar to the existing WebFrameImpl::selectRange. The behavior is similar to how I would expect the following to work:
  selectRange(frame()->selection()->selection().visibleBase(), point);
  selectRange(frame()->selection()->selection().visibleExtent(), frame()->selection()->selection().visibleExtent()); // not sure if .visibleExtent() is correct here

I don't really like doing two select ranges when the first one is really only used to constrain the point to being in the root editable element of the current selection. Also, ::selectRange doesn't appear to honor the platform editing behavior, which is required (though I could be wrong, or maybe it's unintentional).

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