Drop XMLDocument.load() support

RESOLVED FIXED in Firefox 68

Status

()

enhancement
RESOLVED FIXED
14 years ago
7 days ago

People

(Reporter: ian, Assigned: Ehsan)

Tracking

(Blocks 4 bugs, 4 keywords)

Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

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.
Sigh.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Component: DOM: Other → DOM
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.
Blocks: stdglobal
Status: RESOLVED → REOPENED
Depends on: 494705, 1310275
OS: Linux → All
Hardware: x86 → All
Resolution: WONTFIX → ---
Summary: Drop document.load() support → Drop XMLDocument.load() support
> 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.
Flags: needinfo?(ehsan)
Sounds good, I'll hide these behind a pref.
Flags: needinfo?(ehsan)
Component: DOM → DOM: Core & HTML
Attachment #9022496 - Attachment is obsolete: true
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/66f817c81f0d
Disable the XMLDocument.load() API on trunk; r=bzbarsky
Status: ASSIGNED → RESOLVED
Closed: 14 years ago3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Followup for actual removal, please.

Flags: needinfo?(ehsan)

(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

Flags: needinfo?(ehsan)

(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!

Flags: needinfo?(e7358d9c)

(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).

Flags: needinfo?(e7358d9c)

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.

Flags: needinfo?(e7358d9c)

(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.

Flags: needinfo?(e7358d9c)
Blocks: 1546112
Type: defect → enhancement
Regressions: 1561036
See Also: → 1565418
Regressions: 1565418
See Also: 1565418
You need to log in before you can comment on or make changes to this bug.