Bug 61788

Summary: [GTK] Utility methods for UA spellchecking
Product: WebKit Reporter: Xan Lopez <xan.lopez>
Component: WebKitGTKAssignee: Xan Lopez <xan.lopez>
Status: RESOLVED FIXED    
Severity: Normal CC: mrobinson, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Xan Lopez
Reported 2011-05-31 08:58:12 PDT
Patch coming.
Attachments
Patch (4.84 KB, patch)
2011-05-31 09:04 PDT, Xan Lopez 		no flags
DetailsFormatted DiffDiff
Patch (4.83 KB, patch)
2011-06-01 10:09 PDT, Xan Lopez 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Xan Lopez
Comment 1 2011-05-31 09:04:22 PDT
Created attachment 95439 [details] Patch
Martin Robinson
Comment 2 2011-05-31 09:13:51 PDT
Comment on attachment 95439 [details] Patch These methods are on WebFrame in Chromium. What's the reasoning behind having them in WebView here?
Xan Lopez
Comment 3 2011-05-31 09:35:00 PDT
Since they operate on the selection/caret and there can be only one of those it seemed to me the common case is just "give me the stuff wherever it is", so I put them in WebView. If they were in Frame you'd need to figure out what frame you want to use from the UA. Not sure what's the reasoning behind having them in Frame for Chrome.
Martin Robinson
Comment 4 2011-05-31 16:50:39 PDT
(In reply to comment #3) > Since they operate on the selection/caret and there can be only one of those it seemed to me the common case is just "give me the stuff wherever it is", so I put them in WebView. If they were in Frame you'd need to figure out what frame you want to use from the UA. Not sure what's the reasoning behind having them in Frame for Chrome. Each frame has its own selection and caret actually. The correct approach probably involves moving from the hit test result of the context click, unfortunately.
Xan Lopez
Comment 5 2011-06-01 04:12:22 PDT
(In reply to comment #4) > Each frame has its own selection and caret actually. The correct approach probably involves moving from the hit test result of the context click, unfortunately. Is this ever exposed to the user? The usual way to access this from the DOM is window.getSelection(), which seems to assume that there's only one selection that you could possibly care about at any given time. I figured window ~= view and ran with that.
Xan Lopez
Comment 6 2011-06-01 10:09:34 PDT
Created attachment 95619 [details] Patch
Martin Robinson
Comment 7 2011-06-01 10:24:41 PDT
Comment on attachment 95619 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=95619&action=review Great! > Source/WebKit/gtk/webkit/webkitwebframe.cpp:1009 > + * Returns: a #WebKitDOMRange spanning the word, if any, where the > + * caret currently is positioned Should probably say something like: a #WebKitDOMRange spanning the word where the caret is currently positioned. If there is no caret this method returns null. Explicitly mentioning null here is a tipoff to embedders that they need to handle that.
Xan Lopez
Comment 8 2011-06-01 10:41:49 PDT
Comment on attachment 95619 [details] Patch This is confirmed.
Xan Lopez
Comment 9 2011-06-01 10:42:04 PDT
Landed in r87823, closing.
Note You need to log in before you can comment on or make changes to this bug.