[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


marco.barisione at collabora.co.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-                     |gns at gnome.org
                   |unassigned at lists.webkit.org |




------- Comment #29 from marco.barisione at collabora.co.uk  2008-08-06 10:01 PDT -------
(In reply to comment #28)
> Created an attachment (id=22605)
 --> (https://bugs.webkit.org/attachment.cgi?id=22605&action=view) [edit]
> proposed patch

Oepning a new window from the context menu doesn't work here: the new page/tab
is opened but the navigation doesn't occur. How did you test it? Are you
manually navigating to the web page manually from the create-web-view handler?


This is the behaviour in the three different cases we can have:

target=_"blank":
- FrameLoaderClient::dispatchCreatePage()
- We emit create-web-view:
  - ResourceRequest not available -> WebKitNetworkRequest with a NULL uri
  - WindowFeatures not available -> WebKitWebWindowFeatures with default
settings
- FrameLoaderClient::dispatchShow()
- The URL is loaded

Contextual menu:
- ChromeClient::createWindow()
- We emit create-web-view:
  - ResourceRequest available
  - WindowFeatures available
- ChromeClient::setFoo()
- ChromeClient::show()
- We emit show-web-view
- The URL is loaded

window.open() via Javascript:
- ChromeClient::createWindow()
- We emit create-web-view:
  - ResourceRequest not available -> NULL WebKitNetworkRequest
  - WindowFeatures available
- ChromeClient::setFoo()
- ChromeClient::show()
- We emit show-web-view
- The URL is loaded

Unfortunately the ResourceRequest is available only when the link is opened
from the contextual menu, so that parameter seems quite useless atm.
In the case of target="_blank" we have the URL in WebCore so we could just
modify it to pass the URL to FrameLoaderClient::dispatchCreatePage().
In the case of window.open() the URL is not available and the reason is
explained in JSDOMWindowBase.cpp:

// FIXME: It's much better for client API if a new window starts with a URL,
here where we
// know what URL we are going to open. Unfortunately, this code passes the
empty string
// for the URL, but there's a reason for that. Before loading we have to set up
the opener,
// openedByDOM, and dialogArguments values. Also, to decide whether to use the
URL we currently
// do an allowsAccessFrom call using the window we create, which can't be done
before creating it.
// We'd have to resolve all those issues to pass the URL instead of "".

Another problem is the ChromeClient::setFoo() is called for every window
feature, it seems that you are not supposed to set the features from the window
features but when the ChromeClient::setFoo() method is called. This is why
there is a separate ChromeClient::show() method, so you can avoid flickering.

A possible solution is to make the WindowFeatures object just a struct with
public fields and have an empty implementation of the various methods to set
window features in the ChromeClient. In this case we are not losing anything as
those methods are called only before showing the window and are not accessible
in other ways, like js. If we do this we can also kill the show-web-view
signal.


-- 
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.
You are the assignee for the bug, or are watching the assignee.