parseHTML() and parseHTMLUnsafe() documents use an opaque origin

[annevk]

What is the issue with the HTML Standard?

However, tests in web-platform-tests/wpt@35be3b4#diff-03d35d7fd798b2fd1708a1ef5e299e4da01b6788a614a5ff21918067165c2733 contradict this as they assume open() can be called on these documents (open() would throw if the document had an opaque origin).

I think WebKit currently complies with the specification, but we could change this. Not sure if we had a strong reason for the status quo?

[shannonbooth]

Related is #11429

[noamr]

Yea I think this is a dup of #11429.

Some paper trail:
w3c/DOM-Parsing#24

Seems like originally we didn't think of this as observable, but it is using document.domain and document.open(), so let's spec implemented reality (it matches the origin of the document that created it, or some such).

[annevk]

How is it a dupe? They are different APIs. Also, WebKit implements this as specified, but I suppose we can change it.

[noamr]

How is it a dupe? They are different APIs. Also, WebKit implements this as specified, but I suppose we can change it.

I meant that it's the same notion that those document origins are not observable, and doing this for parseHTML originated from the DOMParser API decision, so it's probably one decision for both APIs.

I think it's more useful to spec the Gecko/blink implementation rather than the other way around (why throw exceptions when we don't have to).

[annevk]

I mean document.open() is a bad API so throwing for it doesn't seem too bad, but sure. #12881 fixes both issues.