Dom: Figure out what to do with XMLDocument

[domenic]

Right now createDocument returns an XMLDocument. It has this note:

This method creates an XMLDocument rather than a normal document. They are identical except for the addition of the load() method deployed content relies upon.

Since load() is gone as of https://github.com/whatwg/html/commit/523f7a8773d2ab8a1eb0da6510651e8c5d2a7531, this note needs to be revised at the very least.

Edit: it appears @annevk already removed the note in https://github.com/whatwg/dom/commit/1595762e49358c7da9f6d6f284a3a3ae46987256 :)

I see two options:

• Make XMLDocument another alias of Document, just like HTMLDocument is currently specced to be. Remove all references to XMLDocument from DOM, and have HTML add a sentence about the alias.
• Keep the current empty-derived-interface setup in DOM. Maybe add some disparaging comments about this being a legacy feature.

Personally, I lean toward making it an alias, unless any implementers object. I think that the Document = HTMLDocument = XMLDocument story is a pretty good one, and in Blink at least, we're pretty close to implementing it---there are only a very small number of things left on HTMLDocument, none of which look very problematic. So I'd prefer to continue on that course.

There may be more history here (e.g. implementer objections) of which I am not aware.

[cdumez]

FYI, Safari 9 and earlier had XMLDocument as an alias to Document. However, Safari 10 (which is in public beta) has an XMLDocument interface. We added it (even though empty) in an attempt to align with Firefox and Chrome.

That said, given that it is empty, I would be happy to go back to making it an alias to Document in WebKit.

[annevk]

I guess the main problem with that is the Firefox-only code paths. 😟 I wonder how prevalent those still are.

[foolip]

If Safari had it as an alias for a long time, then it's almost certainly web compatible to make it so. I think we should try to end up in one of these two states:

1. Both HTMLDocument and XMLDocument are aliases of Document.
2. HTMLDocument and XMLDocument are both empty interfaces.

In other words, what to do with XMLDocument I think depends on https://github.com/whatwg/dom/issues/221

[foolip]

HTMLDocument and XMLDocument are both empty interfaces.

In this case, I'm also skeptical of keeping the Document constructor even though Gecko has it already. It would (I think?) be the only way of getting a Document instance that's neither an HTMLDocument nor an XMLDocument instance, which seems like an annoying corner. I didn't dig deeply though.

[annevk]

XMLHttpRequest returns a Document at the moment.

[annevk]

So does DOMParser.

[foolip]

OK, so if dropping the Document constructor, those would also need to switch to HTMLDocument or XMLDocument, whatever it is that implementations without a Document constructor currently do.

But anyway, @cdumez, do you have any preferences here?

[cdumez]

I am pretty sure WebKit has a constructor on Document and I would worry about compatibility if we had to remove it.

[foolip]

Oh, let's take that off the table then, long live new Document()!

It may well be that option 1 from https://github.com/whatwg/dom/issues/278#issuecomment-236557285 won't work out due to compat, but maybe we can investigate and make some good guesses before giving up. Is code that does instanceof HTMLDocument or instanceof XMLDocument the main thing where one should look for breakage, or are there other things to worry about?

[foolip]

I've tried to summarize everything I could find about document interfaces here:
https://gist.github.com/foolip/103963a1ae8598d2baedd296f4a1bf4c

Since the discussion is spread out, I arbitrarily suggest discussing the larger issue in https://github.com/whatwg/dom/issues/221

[bzbarsky]

I guess the main problem with that is the Firefox-only code paths. 😟 I wonder how prevalent those still are.

At first glance our use counter for XMLDocument.load says that 2-3% of page loads use the load() method. I'm not sure how many of those have a fallback for when the method is not there, nor am I sure how many of those (if any) are actually due to extensions. I'm going to try to measure the latter.

[ExE-Boss]

I guess the main problem with that is the Firefox-only code paths. 😟 I wonder how prevalent those still are.

At first glance our use counter for XMLDocument.load says that 2-3% of page loads use the load() method. I'm not sure how many of those have a fallback for when the method is not there, nor am I sure how many of those (if any) are actually due to extensions. I'm going to try to measure the latter.

Well, the extensions which would have used those are no longer supported since Firefox 57.

Also, XMLDocument.load() is finally being removed from Firefox in bug 332175 😁.

[bzbarsky]

Also, XMLDocument.load() is finally being removed from Firefox in bug 332175 😁.

Note that that bug was wontfix until @ExE-Boss just reopened it. Going from that to "is being removed" is ... a bit of a stretch.

Anyway, extensions that might have used XMLDocument.load are not necesarily gone, since webextensions can use it (just like websites).

That said, I just checked our telemetry data for use of XMLDocument.load in Firefox 62 beta and it's at about 300k uses out of 10e9 pageloads, so fairly rare at this point. See https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-08-30&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F62&measure=USE_COUNTER2_DEPRECATED_UseOfDOM3LoadMethod_PAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-06-21&table=0&trim=1&use_submission_date=0

[foolip]

I haven't seen Firefox telemetry before, that's cool! 300k out of 10 billion comes out to 0.003%, which is a small number, but not entirely negligible when it comes to removing things that will start throwing exceptions. Can you tell if the usage is in web contents or extensions?

[bzbarsky]

I don't think I can tell from this use counter as it exists right now.

That said, this use counter only counts cases that have an entry document or are calling load() on an XML document loaded in a browsing context. So it would exclude things like extension content scripts creating XMLDocument instances via DOMImplementation or whatnot and then calling load(). It also includes the Firefox UI itself or things running with "system" privileges (there's a separate use counter for that, but it's a flat 0, which is good).

I could try to separate out extensions more here, but I suspect that all the calls we're still getting are web content...

[bzbarsky]

Oh, one thing I _can_ tell from the telemetry data is that all the accesses were in web content processes: there are 0 samples in the "parent process" bucket and the "content process" number matches the "any process" number. So if extensions _are_ involved it would have to be extension content scripts messing with content XML documents, not a parent-process-side part of the extension UI.

[foolip]

I guess there's no way to work out which sites are responsible, by design? (Chromium has https://chromium.googlesource.com/chromium/src/+/master/services/metrics/ukm_api.md for some use counters, but it only works when the sample size is big enough, and I'm pretty sure 0.003% isn't.)

[bzbarsky]

I guess there's no way to work out which sites are responsible, by design?

Indeed. :(

[ExE-Boss]

Well, XMLDocument.load(…) and XMLDocument.async are now both gone from Firefox 68, and we’ve only had two website breakages so far due to horrible and broken UA sniffing code.

[bzbarsky]

only had two website breakages so far

Only two that got reported via the bug database _and_ identified as regressions from the change, yes?

due to horrible and broken UA sniffing code.

Well, yes, sites that don't do that would not have problems with the removal.

[bzbarsky]

Also, note that one of those two sites was a major bank, and would have been a ship blocker if Firefox didn't also ship a hack to change its UA string on that one site to something that would take us down a different path in the sniffing...

In spec terms, standardizing that sort of thing is of course complicated.

[foolip]

Does this mean that XMLDocument is an empty interface inheriting from Document now in Firefox?

[ExE-Boss]

Not quite, as the non‑standard load and async members have currently only been disabled, but not fully removed yet (this was done to allow an easier rollback in case something were to horribly break).

That said, as far as the web is concerned, XMLDocument is now finally empty in Gecko too.

https://hg.mozilla.org/mozilla-central/file/1097f59d0bc17f6f8f805325c2f607e60cf0d26b/dom/webidl/XMLDocument.webidl

[ExE-Boss]

This is now completely gone from Firefox 71 as of bug 1546112. 🎉

[ExE-Boss]

Anyway, I’m in favour of making XMLDocument an alias to Document.

Although that might break code that does a document instanceof XMLDocument check and expects it to fail for HTMLDocument.

[bzbarsky]

This is now completely gone from Firefox 71

More precisely, XMLDocument is now an empty interface inheriting from Document in Gecko. The interface itself is not gone.

[bzbarsky]

Which seems to also be the case in Chrome and Safari, fwiw.

[foolip]

So... the reasonable thing to do spec-side now is probably to make both HTMLDocument and XMLDocument empty interfaces, possibly with constructors if we think that'd be useful in some way.

[ExE-Boss]

Well, HTMLDocument will most likely contain the named property getter because of https://github.com/whatwg/html/issues/4792.

[foolip]

That would be OK, it's only incompatible with trying to make HTMLDocument an alias of Document in implementations, which I don't think we should try.

[annevk]

XMLDocument is an empty interface already. Maybe we should just close this?

[foolip]

Yeah, https://github.com/whatwg/html/pull/5104 is what seems to remain to settle things, but this issue is done.