Bug 183225 – imported/w3c/web-platform-tests/html/browsers/windows/browsing-context.html fails with async policy delegates

• Component: Page Loading
• Status: RESOLVED FIXED

[Chris Dumez]

imported/w3c/web-platform-tests/html/browsers/windows/browsing-context.html fails with async policy delegates.

[Radar WebKit Bug Importer]

<rdar://problem/38003828>

[Chris Dumez]

Created attachment 334780 [details]
WIP Patch

[Chris Dumez]

Created attachment 334782 [details]
Patch

[Chris Dumez]

Created attachment 334783 [details]
Patch

[Alex Christensen]

Comment on attachment 334783 [details]
Patch

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

> LayoutTests/fast/loader/iframe-src-invalid-url-expected.txt:-3
> - - decidePolicyForNavigationAction 

I agree with the idea that we need to continue synchronously in the WebProcess.  We might need to do a decidePolicyForNavigationAction API call even though we've already continued for API compatibility.

[Chris Dumez]

(In reply to Alex Christensen from comment #5)
> Comment on attachment 334783 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=334783&action=review
> 
> > LayoutTests/fast/loader/iframe-src-invalid-url-expected.txt:-3
> > - - decidePolicyForNavigationAction 
> 
> I agree with the idea that we need to continue synchronously in the
> WebProcess.  We might need to do a decidePolicyForNavigationAction API call
> even though we've already continued for API compatibility.

Can we try this and fall back to doing the IPC if we realize it is really needed?
I do not fully understand why we want to make the IPC call for about:blank.

And we we do the IPC, we have to keep the IPC sync and we'll ignore the client's decision if they respond asynchronously. I'd rather we do not ask the client if we're not always going to obey their decision in all cases.

[Alex Christensen]

Comment on attachment 334783 [details]
Patch

Clients might use this delegate callback to update state about what iframe is showing what URL, not to actually make a decision.  If you're willing to risk breaking such apps, and if you'll keep an eye out for such regressions, I'll r+ this change.

[Chris Dumez]

(In reply to Alex Christensen from comment #7)
> Comment on attachment 334783 [details]
> Patch
> 
> Clients might use this delegate callback to update state about what iframe
> is showing what URL, not to actually make a decision.  If you're willing to
> risk breaking such apps, and if you'll keep an eye out for such regressions,
> I'll r+ this change.

Yes, let's try. We know what to do as a fallback it is does cause breakage. For now, I'd rather try the more aggressive change.

[Chris Dumez]

Comment on attachment 334783 [details]
Patch

Clearing flags on attachment: 334783

Committed r229133: <https://trac.webkit.org/changeset/229133>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.

[Chris Dumez]

Follow-up API test fix in:
https://trac.webkit.org/r229136