Bug 61788 - [GTK] Utility methods for UA spellchecking
Summary: [GTK] Utility methods for UA spellchecking
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Xan Lopez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 08:58 PDT by Xan Lopez
Modified: 2011-06-01 10:42 PDT (History)
2 users (show)

See Also:

Attachments
Patch (4.84 KB, patch)
2011-05-31 09:04 PDT, Xan Lopez 		no flags Details | Formatted Diff | Diff
Patch (4.83 KB, patch)
2011-06-01 10:09 PDT, Xan Lopez 		no flags Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2011-05-31 08:58:12 PDT 
Patch coming.
Comment 1 Xan Lopez 2011-05-31 09:04:22 PDT 
Created attachment 95439 [details]
Patch
Comment 2 Martin Robinson 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?
Comment 3 Xan Lopez 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.
Comment 4 Martin Robinson 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.
Comment 5 Xan Lopez 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.
Comment 6 Xan Lopez 2011-06-01 10:09:34 PDT 
Created attachment 95619 [details]
Patch
Comment 7 Martin Robinson 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.
Comment 8 Xan Lopez 2011-06-01 10:41:49 PDT 
Comment on attachment 95619 [details]
Patch

This is confirmed.
Comment 9 Xan Lopez 2011-06-01 10:42:04 PDT 
Landed in r87823, closing.