[Webkit-unassigned] [Bug 108667] [Chromium] WebWidget should expose a way to determine the start/end of the selection bounds

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Chris Hopman <cjhopman at chromium.org>  2013-02-04 11:22:44 PST ---
(From update of attachment 186088)
View in context: https://bugs.webkit.org/attachment.cgi?id=186088&action=review

>> Source/WebKit/chromium/src/WebViewImpl.cpp:2403
>> +    const Frame* frame = focusedWebCoreFrame();
> 
> I apologize for randomizing you further, but it seems like we might be
> making a mistake by putting all of these selection APIs on WebWidget.
> It seems like all of them act on the focused frame, so perhaps we
> should really be putting selection methods on WebFrame instead.  Then,
> if it is important for selectRange and selectionBounds to be in-sync,
> it'll be more natural because they will be defined adjacent to one
> another.  WDYT?
> 
> The thing to know about WebWidget is that it shouldn't know anything
> about document or frame or any DOM concepts.  It is just a rendering
> surface.  Originally, selection stuff ended up on WebWidget because
> selection as a concept was just a rectangular region of the widget,
> but maybe in hindsight that was a poor choice.

I noticed that WebWidget was an odd place for these methods. 
It looks to me that both the selection and the composition methods 
could/should be moved to WebFrame. There are also four
selection/composition methods on WebView (curiously listed under GPU
acceleration support in WebView.h) that should probably also be
moved then.

I can move the selection APIs to WebFrame first, then add this.

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