Bug 170906 – WKNavigationAction._shouldOpenExternalSchemes should return false for cross-frame navigations

• Status: NEW
• Component: WebKit API

[Ansh Shukla]

Currently, if page A spawns page B using window.open, A can then navigate B by updating its window.location property. The decidePolicyNavigationAction callback that Safari gets when this happens will have a WKNavigationAction with null sourceFrame. We would like a way to detect when one page is navigating another through a window reference acquired through window.open. One way to do this would be to have a sourceFrame which correctly attributes the navigation to the frame whose JavaScript updated the window.location property.

Currently, it seems that all navigations triggered by changing the window.location property have null sourceFrame. This enhancement request is to have the callback pass the frame where JS updated window.location as the sourceFrame.

[Radar WebKit Bug Importer]

<rdar://problem/31664561>

[Antti Koivisto]

*** Bug 173013 has been marked as a duplicate of this bug. ***

[Antti Koivisto]

Created attachment 312206 [details]
patch

[Daniel Bates]

Please write a unit test for this change. We have existing TestWebKitAPI unit tests for this SPI.

[Antti Koivisto]

I didn't manage to make a test. The existing api tests for _shouldOpenExternalSchemes don't load anything beyond the test document, they cancel the navigations. Hitting this requires actual js-initiated cross-origin navigation and there is no HTTP server for API tests. 

Maybe there is some good way to fake it but I don't see anything obvious.

[Brady Eidson]

(In reply to Antti Koivisto from comment #5)
> I didn't manage to make a test. The existing api tests for
> _shouldOpenExternalSchemes don't load anything beyond the test document,
> they cancel the navigations. Hitting this requires actual js-initiated
> cross-origin navigation and there is no HTTP server for API tests. 
> 
> Maybe there is some good way to fake it but I don't see anything obvious.

I know it's possible we're resolving this a different way.

But, if we *do* end up taking this patch, there's definitely a way to API-test it to get a cross-origin navigation in TestWebKitAPI, *without* using an httpd: WKURLSchemeHandler and a custom protocol.

[Daniel Bates]

Created attachment 312989 [details]
Example

Example page that can be used to verify the behavior when a parent window navigates a child window using the child window’s Location object.

[Sam Weinig]

(In reply to Antti Koivisto from comment #5)
> I didn't manage to make a test. The existing api tests for
> _shouldOpenExternalSchemes don't load anything beyond the test document,
> they cancel the navigations. Hitting this requires actual js-initiated
> cross-origin navigation and there is no HTTP server for API tests. 
> 
> Maybe there is some good way to fake it but I don't see anything obvious.

While there may be ways to work around this issue on a case by case basis (add SPI to define schemes as being http like, to allow a foo:// navigation bar:// act as a cross origin), I think we really need to solve this problem. Using httpd (or maybe the web-platform-tests python one) could be one solution, though it would be nice if could do it in process.

[Brady Eidson]

(In reply to Sam Weinig from comment #8)
> (In reply to Antti Koivisto from comment #5)
> > I didn't manage to make a test. The existing api tests for
> > _shouldOpenExternalSchemes don't load anything beyond the test document,
> > they cancel the navigations. Hitting this requires actual js-initiated
> > cross-origin navigation and there is no HTTP server for API tests. 
> > 
> > Maybe there is some good way to fake it but I don't see anything obvious.
> 
> While there may be ways to work around this issue on a case by case basis
> (add SPI to define schemes as being http like, to allow a foo:// navigation
> bar:// act as a cross origin), I think we really need to solve this problem.
> Using httpd (or maybe the web-platform-tests python one) could be one
> solution, though it would be nice if could do it in process.

If the goal in this specific case is just to intercept the attempted cross origin navigation, then a custom protocol navigated *to* an http URL should trigger it... right?