Drop XMLDocument.load() support
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: ian, Assigned: ehsan.akhgari)
References
(Blocks 1 open bug)
Details
(4 keywords)
Attachments
(2 files, 1 obsolete file)
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•18 years ago
|
||
I believe we implemented this because IE did and it was used by pages...
Reporter | ||
Comment 2•18 years ago
|
||
That was my recollection too, but I can't find any empirical evidence to support it. Where do we go from here?
![]() |
||
Comment 3•18 years ago
|
||
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.
Reporter | ||
Comment 4•18 years ago
|
||
Well that won't work in Gecko...
Comment 5•18 years ago
|
||
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•18 years ago
|
||
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.
Reporter | ||
Comment 7•18 years ago
|
||
Sigh.
Updated•11 years ago
|
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.
Updated•6 years ago
|
![]() |
||
Comment 9•5 years ago
|
||
> 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•5 years ago
|
||
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 | ||
Updated•5 years ago
|
Assignee | ||
Comment 11•5 years ago
|
||
![]() |
||
Comment 12•5 years ago
|
||
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•5 years ago
|
||
> 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
Assignee | ||
Comment 14•5 years ago
|
||
Sounds good, I'll hide these behind a pref.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 15•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 16•5 years ago
|
||
Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/66f817c81f0d Disable the XMLDocument.load() API on trunk; r=bzbarsky
Comment 17•5 years ago
|
||
bugherder |
Assignee | ||
Comment 19•5 years ago
|
||
(In reply to :Ms2ger (he/him; ⌚ UTC+1/+2) from comment #18)
Followup for actual removal, please.
Comment 20•5 years ago
|
||
Assignee | ||
Comment 21•5 years ago
|
||
(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•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
(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
.
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2019/xmldocument-load-and-xmldocument-async-have-been-removed/
Updated•5 years ago
|
Comment 26•4 years ago
|
||
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•4 years ago
|
||
Has this been reverted in 68.1 ESR?
Yes. See bug 1569102.
Description
•