Bug 17176 – [GTK] API: hovering-over-link and webkit_web_view_open /_load_foo

• Component: WebKit API
• Status: RESOLVED FIXED

[Christian Dywan]

The API of WebKitWebView has two remaining quirks.

1) If you want to load content into the view, you currently have the following functions:
  webkit_web_view_open
  webkit_web_view_load_string
  webkit_web_view_load_html_string
  webkit_web_frame_load_request

That is plain chaos right now. So my suggestion instead is the following:

  webkit_web_view_load_uri
  webkit_web_view_load_string
  webkit_web_view_load_request

  webkit_web_frame_load_uri
  webkit_web_frame_load_string
  webkit_web_frame_load_request

2) WebKitWebView has a signal "hovering-over-link" with the random signature (WebKitWebView*, const gchar* tooltip, const gchar* uri).

I suggest to remove this in favor of "element-motion". Now the uneasy question is what the signature is going to be. In the long term you will probably have a function looking like webkit_web_view_get_element_at_pos returning a DOM element. Right now we should just try to provide the very most common values, which are from my experience:

  link_uri
  image_uri
  is_control
  is_editable_control
  is_password_control

As for how to represent that in API I'm hesitating.

Suggestions, opinions, ideas welcome, especially from hackers that might have a use for something as fancy as custom context menu items.

[Marco Barisione]

(In reply to comment #0)
> 1) If you want to load content into the view, you currently have the following
> functions:
>   webkit_web_view_open
>   webkit_web_view_load_string
>   webkit_web_view_load_html_string
>   webkit_web_frame_load_request
> 
> That is plain chaos right now. So my suggestion instead is the following:
> 
>   webkit_web_view_load_uri
>   webkit_web_view_load_string
>   webkit_web_view_load_request
> 
>   webkit_web_frame_load_uri
>   webkit_web_frame_load_string
>   webkit_web_frame_load_request

I completely agree on this. Alp: what do you think about this API change? If the new API seems ok I can make the required changes and submit a patch for review.

> 2) WebKitWebView has a signal "hovering-over-link" with the random signature
> (WebKitWebView*, const gchar* tooltip, const gchar* uri).
> 
> I suggest to remove this in favor of "element-motion". Now the uneasy question
> is what the signature is going to be. In the long term you will probably have a
> function looking like webkit_web_view_get_element_at_pos returning a DOM
> element. Right now we should just try to provide the very most common values,
> which are from my experience:
> 
>   link_uri
>   image_uri
>   is_control
>   is_editable_control
>   is_password_control
> 
> As for how to represent that in API I'm hesitating.

How about something similar to HitTestResult? At the beginning it could contain just the most important things like a get_link_uri() method, later we can add a method returning the DOM element for more advanced uses.

[Christian Dywan]

Created attachment 27005 [details]
Readjust view and frame loading functions

As suggested above, this patch deprecates:

  webkit_web_view_open
  webkit_web_view_load_html_string

and introduces:

  webkit_web_view_load_uri
  webkit_web_view_load_request

  webkit_web_frame_load_uri
  webkit_web_frame_load_string

For consistency I implemented all functions on the view using the according frame functions.

[Holger Freyther]

Could you post the thread init patch somewhere else? or rs=me on that and just commit it.

[Christian Dywan]

Created attachment 27039 [details]
Readjust view and frame loading functions #2

I want for the rubber stamp for the threading change. Updated patch to not include it anymore.

[Christian Dywan]

Comment on attachment 27039 [details]
Readjust view and frame loading functions #2

2009-02-12  Christian Dywan  <[e-mail]>

        Reviewed by Holger Freyther.

        http://bugs.webkit.org/show_bug.cgi?id=17176
        [GTK] API: hovering-over-link and webkit_web_view_open /_load_foo

        * webkit/webkitwebframe.cpp:
        * webkit/webkitwebframe.h:
        * webkit/webkitwebview.cpp:
        * webkit/webkitwebview.h: Introduce webkit_web_frame_load_uri,
        webkit_web_frame_load_string, webkit_web_view_load_uri and
        webkit_web_view_load_request and unify implementations.

[Christian Dywan]

Created attachment 28030 [details]
Support file paths in _open for compatibility

As discussed, webkit_web_view_open used to support local paths until very recently and some applications rely on this.

So this patch adds a test if the string is actually a local path. We are not changing webkit_web_view_load_uri because that function is new and we don't really encourage this kind of "guessing" on WebKit's side.

I tested it with devhelp, which doesn't show any content anymore due to this regression. Another example would be liferea.

[Gustavo Noronha (kov)]

(In reply to comment #6)
> Created an attachment (id=28030) [review]
> Support file paths in _open for compatibility

Looks good to me, and is release critical in my opinion - we need to get this in before we release.

[Holger Freyther]

Comment on attachment 28030 [details]
Support file paths in _open for compatibility

Okay, you might want to do undo my change to open the results of the webkit tests as well.

[Christian Dywan]

2009-02-28  Christian Dywan  <[e-mail]>

        Reviewed by Holger Freyther.

        * webkit/webkitwebview.cpp: Let webkit_web_view_open add file:// if a
        locale path is passed for compatibility, since we used to support that.