Implement XMLDocument.load

• Component: DOM
• Status: RESOLVED WONTFIX

[olwin]

on http://www.phoenixjp.net/news/us/ news don't appeared, it only work when use 'text mode' :
http://www.phoenixjp.net/news/us/texte.php?

May be a Javascript problem ?

[Alexey Proskuryakov]

This site detects Safari as a modern Mozilla browser (by the user-agent string and the presence of document.implementation.createDocument) and proceeds using DOM3 document.load method, which we do not support yet.

They already have a special case for Opera, maybe it would be possible to convince them to add a similar case for Safari.

[Eric Seidel (no email)]

We could also just implement XMLDocument.load. :)  It can't be that hard... KDOM might even have an implementation we could steal.

[Sam Weinig]

I don't think Document.load is part of the DOM3 Load and Save anymore.  The last draft to support it was from June 19, 2003 (http://www.w3.org/TR/2003/WD-DOM-Level-3-LS-20030619/).  While I do see us implementing the L&S module at some point in the future (perhaps far future), unless this is used widely, it doesn't seem like something we are likely to implement.

[Ojan Vafai]

FWIW, a number of other sites that break for this reason are listed in the Chromium bugs DB. http://code.google.com/p/chromium/issues/detail?id=988

[Eric Seidel (no email)]

*** Bug 19914 has been marked as a duplicate of this bug. ***

[Eric Seidel (no email)]

*** Bug 21935 has been marked as a duplicate of this bug. ***

[Jungshik Shin]

*** Bug 25199 has been marked as a duplicate of this bug. ***

[Jungshik Shin]

http://map.sogou.com is another web site that relies on 'XMLDocument.load'. Johnny is going to contact the sogou.com to use an alternative for Webkit-based browsers.

[Maciej Stachowiak]

I think we should implement the Document.load extension for the sake of Web compatibility. In the short term we may have to evangelize some of the affected sites.

[Jeremy Moskovich]

http://my.ynet.co.il/weather/new/ is another site that uses documnent.load

[Maciej Stachowiak]

http://cms.cern.ch/iCMS/ is another site that relies on Document.load.

http://www.blizzard.com/inblizz/fanart/ScreenShot.shtml used to but was fixed due to evangelism efforts.

[David Kilzer (:ddkilzer)]

<rdar://problem/4489528&6031551>

[johnnyding]

There are more sites which use document.load to load contents.

http://globes.co.il/news/article.aspx (all the globes.co.il URLs load the same page template)
http://my.ynet.co.il/weather/new/ 
http://www.theweathernetwork.com/weather/CAON0512
http://illinoishomepage.net/
http://www.csnradio.com/
http://www.eveningexpress.co.uk/Default.aspx?UserKey=
http://www.lsua.edu/
http://wwwe.way2sms.com/content/index.html
http://www.yescar.cn/szzc/sziframe.html

[Mark Koenen]

I'm working at a company that uses the DOM API library ( http://www.domapi.com/ ) for it's Content Management System. The DOM API library also uses the XMLDocument.load function.

As a result of this our CMS doesn't work in Chrome 3.0 and Safari 4.0. Is there any news on this issue or could someone point us to some page about the "evangelism efforts"? If we can easily rewrite the code to avoid using the XMLDocument.load function then I'm very interested in such code.

Our CMS currently supports IE6, IE7, IE8, FF3.0 and FF3.5. Therefore any workaround has to support those browser versions as well.

Thanks in advance for any tips :)

Mark.

[Alexey Proskuryakov]

> If we can easily rewrite the code to avoid using the
> XMLDocument.load function then I'm very interested in such code.

Yes, one can just use XMLHttpRequest to load XML documents.

[Adam Barth]

This bug has ticked me off for the last time.  Will do.

[Adam Barth]

Created attachment 51341 [details]
Tests

[Alexey Proskuryakov]

We'll probably need cross-origin tests, as well as auth/cookie handling ones.

Can one use load() with a document coming from a subframe, as opposed to something that was just created with DOMImplementation.createDocument?

[Adam Barth]

> We'll probably need cross-origin tests, as well as auth/cookie handling ones.

Yep.  These tests are just to help me get started.  :)

> Can one use load() with a document coming from a subframe, as opposed to
> something that was just created with DOMImplementation.createDocument?

document-load-self.html tests that case for the main frame, which appears to work in Firefox.  I haven't tested the subframe case, but I will.

The big question in my mind is how we're going to do make the network request from a Frameless document.  We might need to grab a document with a Frame on construction (a la XMLHttpRequest).  That will give us a loading machine as well as a security context.

Right now, I'm just starting on the simpler pieces, like creating an IDL file to make these APIs show up on the right objects.

[Alexey Proskuryakov]

> The big question in my mind is how we're going to do make the network request
> from a Frameless document. 

See also: bug 10313, bug 16103.

[Adam Barth]

> See also: bug 10313, bug 16103.

Yep.  I'm tempted to do something simpler here than creating a general-purpose Frameless loading path.  Basically, my plan is to have the DOMImplementation-created document grab a pointer to the Document who's script created it and then use that Document's loading machine.

[Alexey Proskuryakov]

Mozilla was going to deprecate Document.load, but our lack of commitment seems to have stopped or postponed that effort: <https://bugzilla.mozilla.org/show_bug.cgi?id=494705>.

[Adam Barth]

My (anecdotal) experience is that the web isn't quite ready for this API to be removed yet.  If Firefox removed this API, I would have had to dig out my Windows laptop (and IE) to get reimbursed for a recent trip.

[Alexey Proskuryakov]

FWIW, I agree. We seem to be stuck with it.

[Alexey Proskuryakov]

document.load is now defined in HTML5.

[Adam Barth]

*** Bug 45023 has been marked as a duplicate of this bug. ***

[Adam Barth]

Created attachment 66299 [details]
work in progress

[Adam Barth]

Created attachment 66302 [details]
a test

[Tony Gentilcore]

Another broken site: http://code.google.com/p/chromium/issues/detail?id=58613

[Alexey Proskuryakov]

*** Bug 58519 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

HTML5 has specified XMLDocument now (in a way that's very different from Firefox). Document.load now lives in this XMLDocument.

See <http://www.w3.org/Bugs/Public/show_bug.cgi?id=14037>.

[Ian 'Hixie' Hickson]

It is hoped Firefox will converge on this too, as the design was adopted based on discussions with a Gecko developer (bz).

[Annor Mensah]

(In reply to comment #2)
> We could also just implement XMLDocument.load. :)  It can't be that hard... KDOM might even have an implementation we could steal.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.

[Sam Sneddon [:gsnedders]]

XMLDocument.load is no longer supported in any browser, and it seems unlikely that cross-vendor agreement to reintroduce it will be reached at this point.