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

[bugzilla-daemon at webkit.org]

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





------- Comment #16 from marco.barisione at collabora.co.uk  2008-06-22 09:29 PDT -------
(In reply to comment #15)
> (From update of attachment 21464 [edit])
> You should never gtk_widget_show_all on code you did not write. Plus you cannot
> know if there is a toplevel, so you need to check that first. A gtk_widget_show
> might be okay.

Ok for gtk_widget_show() but in this case it should also be called on the
webview too. _get_toplevel() returns the widget itself if there is not
toplevel.

> >+static void webkit_web_view_request_init(WebKitWebViewRequest* request)
> >+{
> >+    request->priv = WEBKIT_WEB_VIEW_REQUEST_GET_PRIVATE(request);
> >+
> >+    WebKitWebViewRequestPrivate* priv = request->priv;
> >+    priv->name = g_strdup("");
> >+    priv->webWindowFeatures = webkit_web_window_features_new();
> >+}
> 
> Why is name initially "" as opposed to NULL?

Don't remember if there was a reason for that, probably NULL is the right
thing.

> >+    g_object_class_install_property(objectClass, PROP_NAME,
> >+                                    g_param_spec_string("name",
> >+                                                        "New window name",
> >+                                                        "The name of the new window",
> >+                                                        "",
> >+                                                        WEBKIT_PARAM_READWRITE));
> 
> I'm not sure about name. It's the name of a "frame" or "window" in HTML terms,
> so it might be better to name it accordingly.

I would say frame-name.

> WebViewRequest might be confusing, looking at NetworkRequest. However I'm not
> quite clear yet as for how this class fits in the interface. It might be less
> confusing in a general context.

I'm not so sure anymore that we need it as both the win and mac port pass to
the delegate just the URI and the window features.

> >+enum {
> >+    PROP_0,
> >+
> >+    PROP_X,
> >+    PROP_Y,
> >+    PROP_WIDTH,
> >+    PROP_HEIGHT,
> >+    PROP_TOOLBAR_VISIBLE,
> >+    PROP_STATUSBAR_VISIBLE,
> >+    PROP_SCROLLBAR_VISIBLE,
> >+    PROP_MENUBAR_VISIBLE,
> >+    PROP_LOCATIONBAR_VISIBLE,
> >+    PROP_RESIZABLE,
> >+    PROP_FULLSCREEN,
> >+    PROP_DIALOG
> 
> If I remember correctly one of these became meaningless at some point, in the
> sense that it causes no error in javascript but is never honored. I think it
> probably was "resizable" but I cannot find the bug number right now.

We will check/ask on #webkit.

> >+    g_object_class_install_property(gobject_class,
> >+                                    PROP_DIALOG,
> >+                                    g_param_spec_boolean(
> >+                                    "dialog",
> >+                                    "Dialog",
> >+                                    "Controls whether window should be a dialog, or a top level window.",
> >+                                    FALSE,
> >+                                    flags));
> 
> What is the exact use case of this? Is this actually something that websites
> make use of/ is in a spec/ has any other relevance?

I think it's a IE extension also supported in WebKit. After the merge of
squirrel fish WebKit doesn't support anymore showModalDialog(), I asked on
#webkit if this is a regression but I got no answer. I will try again and
submit a bug report.


-- 
Configure bugmail: https://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.