Bug 59235 – [Chromium] createWindow() does not pass url to createView() in the case of a FrameLoadRequest

• Component: Platform
• Status: RESOLVED WONTFIX

[anthony taranto]

The url is available if createWindow is called as a result of a NavigationRequest, but not for all cases of FrameLoadRequest.

This patch always passes url to createView() in all cases.

This is required to fix this Chromium Embedded Framework issue:

http://code.google.com/p/chromiumembedded/issues/detail?id=5

Previous mailing list discussion:

http://groups.google.com/group/chromium-dev/browse_thread/thread/6597b4b28e564a95

[anthony taranto]

Created attachment 90765 [details]
fix

[Eric Seidel (no email)]

This is chromium API, right?  That means you need fishd sign-off.

[Darin Fisher (:fishd, Google)]

Comment on attachment 90765 [details]
fix

View in context: https://bugs.webkit.org/attachment.cgi?id=90765&action=review

> Source/WebKit/chromium/public/WebViewClient.h:90
> +                                const WebURL& url,

what does this "url" refer to, and under what conditions does it differ from request.url()?

it is very confusing for this method to be passed two "urls"... which one is meaningful to
the implementer of the createView method?  perhaps we should make sure that request.url()
is always meaningful?

[Darin Fisher (:fishd, Google)]

R- because there is no explanation for why these URLs are different.

[Marshall Greenblatt]

Darin, the problem is that r.resourceRequest() is null in ChromeClientImpl::createWindow() when clicking a link with target="_blank". It might be best to create a request object in ChromeClientImpl::createWindow() with just the URL component from NavigationAction and pass that as the request argument to WebViewClient::createView().

[Stephen Chenney]

Assuming fixed or no longer relevant as this is an old issue. Reopen in crbug if that's not true.