imported/w3c/web-platform-tests/html/browsers/windows/browsing-context.html fails with async policy delegates.
<rdar://problem/38003828>
Created attachment 334780 [details] WIP Patch
Created attachment 334782 [details] Patch
Created attachment 334783 [details] Patch
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.
(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.
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.
(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.
Comment on attachment 334783 [details] Patch Clearing flags on attachment: 334783 Committed r229133: <https://trac.webkit.org/changeset/229133>
All reviewed patches have been landed. Closing bug.
Follow-up API test fix in: https://trac.webkit.org/r229136