Bug 9063

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.

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

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.

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

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

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

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

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.

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.

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

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.

<rdar://problem/4489528&6031551>

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

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.

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

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

Created attachment 51341 [details] Tests

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?

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

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

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

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

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.

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

document.load is now defined in HTML5.

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

Created attachment 66299 [details] work in progress

Created attachment 66302 [details] a test

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

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

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

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

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

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

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.