Audit "active document" checks #3812
Description
Most places in the spec that want to disallow "bad documents" from doing things check if the document is fully active.
A few places seem to check whether the document is active. I'm unsure whether this is ever a good idea:
- Fully active is the more restrictive check. Being more restrictive is generally a good idea in these scenarios.
- The way the terms are defined, it seems like they're expected to be used with "X is fully active" being a boolean predicate, and "X's active document" being a way of navigating through the spec-object graph. "X is an active document" does not fit super-well with the definitions.
I am not sure I have exhaustively found all such "active document" checks. But, I Ctrl+Fed for "is an active document" and "is not an active document", and found the following:
- Aborting a document load: not interoperable, per "abort" Event Isn't Fired When Aborting Document Load #3525.
- img.decode(): this was recently introduced, and may have been a mistake
- document.open() + document.write(): not interoperable, per Extend document.open/write to non-active documents #2827.
- document.open() alias for window.open(): unsure what's going on here, but maybe carry-over from its proximity to document.open()/document.write() in the spec. Needs interop testing.
A plausible path forward here, that I would prefer, is:
- Fix the interop issues for aborting and document.open()/document.write(), which will result in removing these "active document" checks
- Change img.decode() to test fully active, not just active
- Change the document.open()-alias-for-window.open() case either to remove the check, or strengthen it to fully active, depending on the results of interop testing.
This plan may fall apart if my Ctrl+F was incomplete, and I've misunderstood the scope of the problem.
/cc @bzbarsky @annevk as people with lots of knowledge about this area.