Ensure PDF browsing contexts have no DOM

[domenic]

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.

• At least two implementers are interested (and none opposed):
  • Gecko implements this
  • @rniwa @mfreed7 would you be willing to make this change in WebKit/Chromium? It should be pretty safe I'd imagine...
• Tests are written and can be reviewed and commented upon at:
  • Test that plugin documents are not accessible web-platform-tests/wpt#29957
• Implementation bugs are filed:
  • Chrome: TODO
  • Firefox: N/A
  • Safari: TODO

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )
/index.html ( diff )
/origin.html ( diff )

[annevk]

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.

[mfreed7]

Sorry for the delay reviewing this. I'm generally supportive of the idea - I think it makes sense to remove the <embed> usage entirely and just have PDFs be inline content (no DOM). I have not had a chance to look into the Blink implementation to see how much of a change that'd be. I do suspect, as you mentioned, that this change should be fairly web compatible, though there might be some corner cases where people are using the knowledge that they can see into the PDF document and do things. But if they did that, I would think they should know they're doing things that might break in the future, and clearly it already wouldn't work on e.g. Firefox.

I've filed this Chromium bug to kick off the implementation question.

[mfreed7]

Quick clarification here. Implementation-wise, if we were to just make <iframe src=myfile.pdf> always cross-origin to the embedding page, that would be new-spec compliant, correct? That appears to be how Mozilla works today.

[domenic]

Yep, that's exactly right.

[mfreed7]

Yep, that's exactly right.

Thanks!