[Webkit-unassigned] [Bug 178720] [GTK][WPE] Switch to use API::NavigationClient

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 24 23:27:55 PDT 2017


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

--- Comment #4 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Alex Christensen from comment #3)
> (In reply to Carlos Garcia Campos from comment #1)
> > Created attachment 324664 [details]
> > WIP
> > 
> > I've started to work on this, but I need some more feedback to finish it:
> > 
> >  - API::NavigationClient::decidePolicyForNavigationAction() is now used for
> > both decidePolicyForNavigationAction and decidePolicyForNewWindowAction, but
> > it doesn't provide the frame name. Is there any other way to get it?
> Could we add that to API::FrameInfo?

No, at this point the frame doesn't really exist, we only have a name. I think we could add it to NavigationAction as targetFrameName().

> > 
> >  - Why API::Navigationclient::decidePolicyForNavigationResponse() receives a
> > non-const NavigationResponse reference? Shouldn't it receive a
> > Ref<NavigationResponse>&& instead?
> Sure.

I'll do it then.

> > 
> >  - WebPageProxy::decidePolicyForNewWindowAction() creates the
> > API::NavigationAction using the request URL as original URL this way
> > WTFMove(request), request.url(). I think this is using request after the
> > move.
> Parameter evaluation order is undefined behavior.  Right now it probably
> works correctly on some systems.  We should move the request.url() to the
> previous line to make sure we use a copy of the URL.  Good catch!
> 
> (In reply to Carlos Garcia Campos from comment #2)
> > Forgot another question:
> > 
> >  - didDisplayInsecureContentForFrame() and didRunInsecureContentForFrame()
> > are only provided by the LoaderClient, so I could remove the policy client
> > implementation, but not the loader client one.
> If they're used, we should add them to the navigation client instead of the
> loader client.  If they're not used we should remove them.

Yes, we expose this in our API, I'll add those methods to the navigation client then, and remove the GLib loader client.

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


More information about the webkit-unassigned mailing list