[Webkit-unassigned] [Bug 146589] [GTK] Add API to WebKitWebsiteDataManager to handle cached data

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 28 09:05:28 PDT 2015


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

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com

--- Comment #9 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to comment #7)
> 
> This is a common thing we do in the API just to make it more convenient to
> use. The host and protocol are stored in WebCore::SecurityOrigin as String,
> but all our APIs return always string in utf8 (like all other GNOME platform
> APIs). If we return the converted string directly, the returned value should
> be freed by the user. So, we cache the converted strings to be able to
> return a const char *, and we do that only on demand, so if you never call
> get_host we don't have a cached value for nothing.

Surely if we were to take a String s and return s.utf8().data(), that does not need to be freed by the caller. It is a pointer to the CString's internal CStringBuffer. And the CString has a reference-counted CStringBuffer, so the data should be freed automatically when... er, when the function returns. Ah, OK, so that would be bad. WebKit's strings are confusing; I wish it hadn't taken a year for me to realize this.

> > > Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:77
> > > +    ASSERT(origin);
> > 
> > When you would write an assertion like this, I think it's better to pass by
> > reference instead. I think we've been trying to avoid pass by pointer except
> > in C API and when the pointer is expected to be null.
> 
> WebKitSecurityOrigin is a boxed type not a C++ class, we always use pointers
> with GObjects or boxed types.

I am not sure why, though. I think it would still work fine if we were to do pass by reference.

> > > Source/WebKit2/UIProcess/API/gtk/WebKitSecurityOrigin.cpp:166
> I thought nullable/allow-none was assumed for char *, I think we don't use
> that in any of our APIs, we will have to update them all.

I think that is wrong, unfortunately. I found [1] which says:

gchar* means (type utf8) (transfer full)
const gchar* means (type utf8) (transfer none)

Where (nullable) is conspicuously missing. And it includes this example:

/**
 * gtk_link_button_new_with_label: 
 * @uri: A URI
 * @label: (nullable): A piece of text or NULL
 */
GtkWidget *
gtk_link_button_new_with_label (const gchar *uri,
                                const gchar *label);

So I think we've been doing it wrong.

Looking at [1], it does look like no annotations are needed for GError, so you're right about that. I was looking at some Gio code that used (out), but I guess it was redundant.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150728/fb2afe65/attachment-0001.html>


More information about the webkit-unassigned mailing list