Repository navigation
Conversation
b319de1 to
c743dac
Compare
annevk
left a comment
There was a problem hiding this comment.
Thanks for tackling this. I'm definitely supportive of not exposing these documents. I suspect it needs to be rebased due to removal of "secured" plugins.
Previously, the spec allowed either the "page load processing model for content that uses plugins" or the "page load processing model for inline content that doesn't have a DOM" to be used for PDFs. The observable difference was that plugin documents could be same-origin to their containing page, allowing the containing page to observe the <embed> element etc. Since Firefox manages to get away with the "no DOM" path, and that path is simpler, we make it the only allowed path. This also fixes a few bugs in the no-DOM processing model: * If it was reached for the PDF case, there was no check to disallow viewing the PDF in a sandboxed browsing context. * It was passing a null request to the Document creation algorithm, which was not allowed. * It would lose the history handling behavior, so it would not properly do replace navigations if requested. * It would lose the navigation id, so it would not properly signal the results to WebDriver BiDi. * It was missing a few other navigation params fields.
c743dac to
b23a5c9
Compare
|
Sorry for the delay reviewing this. I'm generally supportive of the idea - I think it makes sense to remove the I've filed this Chromium bug to kick off the implementation question. |
|
Quick clarification here. Implementation-wise, if we were to just make |
|
Yep, that's exactly right. |
Thanks! |
…sible, a=testonly Automatic update from web-platform-tests Test that plugin documents are not accessible Follows whatwg/html#6947. -- wpt-commits: 3f920a2c943783e2513957fe55cfde412ea603fc wpt-pr: 29957
…sible, a=testonly Automatic update from web-platform-tests Test that plugin documents are not accessible Follows whatwg/html#6947. -- wpt-commits: 3f920a2c943783e2513957fe55cfde412ea603fc wpt-pr: 29957
…sible, a=testonly Automatic update from web-platform-tests Test that plugin documents are not accessible Follows whatwg/html#6947. -- wpt-commits: 3f920a2c943783e2513957fe55cfde412ea603fc wpt-pr: 29957
Previously, the spec allowed either the "page load processing model for content that uses plugins" or the "page load processing model for inline content that doesn't have a DOM" to be used for PDFs. The observable difference was that plugin documents could be same-origin to their containing page, allowing the containing page to observe the
<embed>element etc.Since Firefox manages to get away with the "no DOM" path, and that path is simpler, we make it the only allowed path.
This also fixes a few bugs in the no-DOM processing model:
(See WHATWG Working Mode: Changes for more details.)
/browsing-the-web.html ( diff )
/index.html ( diff )
/origin.html ( diff )