Closed Bug 332175 Opened 18 years ago Closed 5 years ago
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.
I believe we implemented this because IE did and it was used by pages...
That was my recollection too, but I can't find any empirical evidence to support it. Where do we go from here?
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.
Well that won't work in Gecko...
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.
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
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.
> 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...
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.
Assignee: general → ehsan
Status: REOPENED → ASSIGNED
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.
> 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
Sounds good, I'll hide these behind a pref.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/66f817c81f0d Disable the XMLDocument.load() API on trunk; r=bzbarsky
You need to log in before you can comment on or make changes to this bug.