332175 - Drop XMLDocument.load() support

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

[Hixie (not reading bugmail)]

I'd like to propose that we drop support for document.load(). DOM3 LS has not received much traction on the Web, and document.load() doesn't seem to be in the final version of that spec anyway. XMLHttpRequest has become the de-facto way of doing external file loads.

I think dropping document.load() would reduce our attack surface area a little, and would reduce our overall complexity, which is a good thing.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I believe we implemented this because IE did and it was used by pages...

Comment 2

[Hixie (not reading bugmail)]

That was my recollection too, but I can't find any empirical evidence to support it. Where do we go from here?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Some googling suggests this ought to work in IE:

  xml_doc = new ActiveXObject("Microsoft.XMLDOM");
  xml_doc.async = false;
  xml_doc.load("stuff.xml");

It's documented on sites like w3schools.com, www.devguru.com, etc.

Comment 4

[Hixie (not reading bugmail)]

Well that won't work in Gecko...

Comment 5

[James Ross]

I've seen people do that in #js recently (though with the DOMImplementation way of creating a document). I don't know if that is mentioned on the web anywhere, but they obviously worked out how to do it.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The MS way of creating an XMLHttpRequest object doesn't work in Gecko either, last I checked (though I hear that Microsoft is implementing the constructor approach).  Sites that use this create a document through DOMImplementation or ActiveX based on object sniffing, then use the shared load() codepath.

Comment 7

[Hixie (not reading bugmail)]

Sigh.

Comment 8

[ExE Boss]

Now that this has been deprecated and there’s a functioning deprecation warning thanks to bug 494705 and bug 1310275, I’m reopening this and adding it as a blocker to bug 916605, since this is highly unlikely to break webcompat as Google Chrome never supported this in the first place and Firefox is the only remaining browser to have implemented this.

Also we have the Fetch API now.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Also we have the Fetch API now.

The overlap between sites that used this API and that might use the fetch API is probably the empty set...

Comment 10

[Andrew McCreight [:mccr8]]

I think this is what the XMLDocument.load subtest of /dom/historical.html historical is testing. It fails in Firefox but passes in the other browsers.

Comment 11

[(no longer active)]

Attachment: Bug 332175 - Remove XMLDocument.load()

Comment 12

[Boris Zbarsky [:bzbarsky]]

What is the current compat situation?  Use counter is showing nonzero usage...

I would be somewhat happier about putting this behind a pref we turn off, so we can respond to potential compat issues quickly.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Use counter is showing nonzero usage.

But pretty low.  See https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-10-01&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=0&sort_keys=submissions&start_date=2018-05-08&table=0&trim=1&use_submission_date=0

Comment 14

[(no longer active)]

Sounds good, I'll hide these behind a pref.

Comment 15

[(no longer active)]

Attachment: Bug 332175 - Disable the XMLDocument.load() API on trunk;

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66f817c81f0d
Disable the XMLDocument.load() API on trunk; r=bzbarsky

Comment 17

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/66f817c81f0d

Comment 18

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Followup for actual removal, please.

Comment 19

[(no longer active)]

(In reply to :Ms2ger (he/him; ⌚ UTC+1/+2) from comment #18)

Followup for actual removal, please.

https://bugzilla.mozilla.org/show_bug.cgi?id=1328138#c17

Comment 20

[ExE Boss]

Attachment: MDN: Browser compatibility table update

Comment 21

[(no longer active)]

(In reply to ExE Boss from comment #20)

Thanks for helping with the docs update. Is it possible to avoid publicizing these pref names? They're not really intended for users to set them. They exist for us to be able to set them as part of an emergency hotfix release if it turns out that these changes break an important website.

Thanks!

Comment 22

[ExE Boss]

(In reply to :Ehsan Akhgari from comment #21)

(In reply to ExE Boss from comment #20)

Thanks for helping with the docs update. Is it possible to avoid publicizing these pref names? They're not really intended for users to set them. They exist for us to be able to set them as part of an emergency hotfix release if it turns out that these changes break an important website.

Thanks!

I’ll leave that decision up to the BCD owners listed in: mdn/browser‑compat‑data#3981 (comment).

Comment 23

[Chris Mills [:cmills]]

I’ll leave that decision up to the BCD owners listed in: mdn/browser‑compat‑data#3981 (comment).

I'd be perfectly happy with removing the prefs from the compat data. I think it is good to publicize prefs when we are providing an experimental new feature behind a flag that we want devs to activate, play with, provide feedback, etc.

But this is not the case here — this is an old feature that is being disabled by beig put behind a disabled pref, so there is little value in it being played with and turned back on, except by the engineers in the event of a site compat issue.

So Exe-Boss, can you update your BCD PR as appropriate? Thanks.

Comment 24

[ExE Boss]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #23)

I’ll leave that decision up to the BCD owners listed in: mdn/browser‑compat‑data#3981 (comment).

I'd be perfectly happy with removing the prefs from the compat data. I think it is good to publicize prefs when we are providing an experimental new feature behind a flag that we want devs to activate, play with, provide feedback, etc.

But this is not the case here — this is an old feature that is being disabled by beig put behind a disabled pref, so there is little value in it being played with and turned back on, except by the engineers in the event of a site compat issue.

So ExE Boss, can you update your BCD PR as appropriate? Thanks.

Done in commit mdn/browser‑compat‑data@8905a43.

Comment 25

[Kohei]

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2019/xmldocument-load-and-xmldocument-async-have-been-removed/

Comment 26

[Christian Hartmann]

Has this been reverted in 68.1 ESR? I found a default pref in my installation: dom.xmldocument.load.enabled = true and dom.xmldocument.async.enabled = true

Comment 27

[Boris Zbarsky [:bzbarsky]]

Has this been reverted in 68.1 ESR?

Yes. See bug 1569102.