[Webkit-unassigned] [Bug 19130] ChromeClient::createWindow and friends need to be implemented

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 26 17:57:48 PDT 2008


------- Comment #8 from gns at gnome.org  2008-05-26 17:57 PDT -------
> - It's not clear from the documentation who is the owner of the object returned
> by "create-web-view". IMHO we are doing the right thing without calling
> g_object_ref in the callback as the reference will be owned by the window, but
> then we have to document this and to get the reference count right (i.e. use
> g_value_take object in the accumulator/unref the value returned by the emission
> of the signal).

with regards to the ref count, I made some testing and it seems to me like it
is correct the way it is now; GSignal is probably doing some unref magic along
the way, because the ref count gets to the signal emiter as 1, even though it
is at 2 after g_value_set_object; and if I replace g_value_set_object with
g_value_take_object in the accumulator I end up having all kinds of g_critical
messages, even without doing a g_object_unref:

(lt-GtkLauncher:11414): GLib-GObject-WARNING **: instance with invalid (NULL)
class pointer

(lt-GtkLauncher:11414): GLib-GObject-CRITICAL **: g_signal_emit_valist:
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(lt-GtkLauncher:11414): GLib-GObject-WARNING **: instance with invalid (NULL)
class pointer

(lt-GtkLauncher:11414): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(lt-GtkLauncher:11414): GLib-GObject-WARNING **: instance with invalid (NULL)
class pointer

(lt-GtkLauncher:11414): GLib-GObject-CRITICAL **: g_signal_handlers_destroy:
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(lt-GtkLauncher:11414): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(lt-GtkLauncher:11414): GLib-GObject-CRITICAL **: g_object_unref: assertion
`G_IS_OBJECT (object)' failed

So I think perhaps we don't need handling different than what we have now?

> - Use the exact type when registering new signals, not just G_TYPE_OBJECT.


> - How about replacing locationbar with uribar? We use uri in every other place,
> but I don't know what I prefer. In both cases I would prefer to separate bar
> from the previous word but then it wouldn't be consistent with the other names.

Not a lot of precedence set for this one. Perhaps uri_entry, since it is not
really a 'bar' like the others? I'm not changing this one for now so we can
discuss and reach some consensus.

> - The default value for resizable should be TRUE.

Gah. Bad copy/paste =)

> - WebKitWebFeatures doesn't have functions to access directly properties but
> probably it's better this way than adding a lot of getters/setters.

I would rather keep it that way. g_object_{set,get} are convenient enough, and
we're not deviating from stuff such as WebKitWebSettings, which has properties
only accessible through the GObject generic accessors.

> - g_object_notify() is needed only in functions setting values not in the
> implementation of set_property as g_object_set_property already emits it.
> - Change the _set_window_features() function to set it only if it's different
> from the previous one and to use g_object_notify() after setting it. I know
> that other properties are not doing it but there is a bug open about this (see
> bug #18405).


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

More information about the webkit-unassigned mailing list