Drop XMLDocument.load() support

ASSIGNED
Assigned to

Status

()

ASSIGNED
13 years ago
a month ago

People

(Reporter: ian, Assigned: Ehsan)

Tracking

(Blocks: 3 bugs, {site-compat})

Trunk
site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 2

13 years ago
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.
(Reporter)

Comment 4

13 years ago
Well that won't work in Gecko...

Comment 5

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

13 years ago
Sigh.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
Component: DOM: Other → DOM
Product: Core → Core

Comment 8

5 months 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.
Blocks: 916605
Status: RESOLVED → REOPENED
Depends on: 494705, 1310275
OS: Linux → All
Hardware: x86 → All
Resolution: WONTFIX → ---
Summary: Drop document.load() support → Drop XMLDocument.load() support
Keywords: site-compat
> 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.
Blocks: 1498357

Updated

2 months ago
Blocks: 1254929
(Assignee)

Updated

a month ago
Assignee: general → ehsan
Status: REOPENED → ASSIGNED
(Assignee)

Comment 11

a month ago
Created attachment 9022496 [details]
Bug 332175 - Remove XMLDocument.load()
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)
(Assignee)

Comment 14

a month ago
Sounds good, I'll hide these behind a pref.
Flags: needinfo?(ehsan)
You need to log in before you can comment on or make changes to this bug.