.
<rdar://problem/86897770>
Created attachment 447988 [details] Patch
Created attachment 448188 [details] Rebase on trunk
Comment on attachment 448188 [details] Rebase on trunk View in context: https://bugs.webkit.org/attachment.cgi?id=448188&action=review > Source/WebCore/page/ModalContainerObserver.cpp:67 > - if (!document.url().protocolIsInHTTPFamily()) > + if (!document.topDocument().url().protocolIsInHTTPFamily()) Should this check both documents? (I'm not sure what the HTTP-family check is *for*, so the answer could easily be yes OR no, I'm not sure)
Comment on attachment 448188 [details] Rebase on trunk View in context: https://bugs.webkit.org/attachment.cgi?id=448188&action=review Thanks for the review! >> Source/WebCore/page/ModalContainerObserver.cpp:67 >> + if (!document.topDocument().url().protocolIsInHTTPFamily()) > > Should this check both documents? (I'm not sure what the HTTP-family check is *for*, so the answer could easily be yes OR no, I'm not sure) Good question! So I *think* the top document URL check should suffice. As far as I understand, this check is here because the feature that this "modal container observation" mechanism drives is only intended to take effect when navigating to http URLs, as opposed to file:// or any custom schemes, so this basically just acts as a way to short circuit the detection logic early on in the case where the document isn't HTTP/HTTPS. In the subframe case in particular, the..."semantically interesting" content of the modal container can come in the form of a data: URL on the iframe or the `srcdoc` attribute, in which case the URL will not be in the HTTP family (but we'll still need to descend into these frames for the purposes of modal container detection) — so in the case where the sub-document is non-HTTP-family, we don't want to bail early here.
Committed r287588 (245717@main): <https://commits.webkit.org/245717@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 448188 [details].