Bug 9063

Summary: Implement XMLDocument.load
Product: WebKit Reporter: olwin <olwin>
Component: DOMAssignee: Adam Barth <abarth>
Status: NEW ---    
Severity: Normal CC: abarth, alurib, anantha, annormensah, ap, cdumez, ddkilzer, dglazkov, dominicc, ian, jayvdb, jeremybonan, johnnyding.webkit, jshin, marcus, playmobil, sam, shadow2531, thenose_, tonyg, webkit, xlyuan
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://www.phoenixjp.net/news/us/
Bug Depends on: 36480, 36465    
Bug Blocks: 10489, 26093, 26563, 32444, 14589    
Attachments:
Description Flags
Tests
none
work in progress
none
a test none

Description olwin 2006-05-23 10:28:27 PDT
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 ?
Comment 1 Alexey Proskuryakov 2006-05-23 12:48:39 PDT
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.
Comment 2 Eric Seidel (no email) 2006-05-23 12:54:59 PDT
We could also just implement XMLDocument.load. :)  It can't be that hard... KDOM might even have an implementation we could steal.
Comment 3 Sam Weinig 2006-12-08 16:21:07 PST
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.
Comment 4 Ojan Vafai 2008-09-09 20:24:20 PDT
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
Comment 5 Eric Seidel (no email) 2008-10-29 10:42:53 PDT
*** Bug 19914 has been marked as a duplicate of this bug. ***
Comment 6 Eric Seidel (no email) 2008-10-29 10:43:17 PDT
*** Bug 21935 has been marked as a duplicate of this bug. ***
Comment 7 Jungshik Shin 2009-04-15 12:04:23 PDT
*** Bug 25199 has been marked as a duplicate of this bug. ***
Comment 8 Jungshik Shin 2009-04-15 12:14:31 PDT
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.
Comment 9 Maciej Stachowiak 2009-05-11 19:35:00 PDT
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.
Comment 10 Jeremy Moskovich 2009-05-19 16:01:30 PDT
http://my.ynet.co.il/weather/new/ is another site that uses documnent.load
Comment 11 Maciej Stachowiak 2009-05-20 05:24:33 PDT
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.
Comment 12 David Kilzer (:ddkilzer) 2009-05-22 10:13:05 PDT
<rdar://problem/4489528&6031551>
Comment 14 Mark Koenen 2010-01-21 01:34:26 PST
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.
Comment 15 Alexey Proskuryakov 2010-01-21 08:32:46 PST
> 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.
Comment 16 Adam Barth 2010-03-18 20:18:54 PDT
This bug has ticked me off for the last time.  Will do.
Comment 17 Adam Barth 2010-03-22 13:30:26 PDT
Created attachment 51341 [details]
Tests
Comment 18 Alexey Proskuryakov 2010-03-22 13:49:20 PDT
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?
Comment 19 Adam Barth 2010-03-22 15:00:10 PDT
> 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.
Comment 20 Alexey Proskuryakov 2010-03-22 15:04:16 PDT
> 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.
Comment 21 Adam Barth 2010-03-22 15:07:28 PDT
> 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.
Comment 22 Alexey Proskuryakov 2010-03-23 16:36:43 PDT
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>.
Comment 23 Adam Barth 2010-03-23 16:55:11 PDT
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.
Comment 24 Alexey Proskuryakov 2010-03-23 17:06:45 PDT
FWIW, I agree. We seem to be stuck with it.
Comment 25 Alexey Proskuryakov 2010-08-02 12:10:03 PDT
document.load is now defined in HTML5.
Comment 26 Adam Barth 2010-09-01 11:28:25 PDT
*** Bug 45023 has been marked as a duplicate of this bug. ***
Comment 27 Adam Barth 2010-09-01 16:27:49 PDT
Created attachment 66299 [details]
work in progress
Comment 28 Adam Barth 2010-09-01 17:17:15 PDT
Created attachment 66302 [details]
a test
Comment 29 Tony Gentilcore 2010-10-20 10:24:40 PDT
Another broken site: http://code.google.com/p/chromium/issues/detail?id=58613
Comment 30 Alexey Proskuryakov 2011-04-18 20:01:00 PDT
*** Bug 58519 has been marked as a duplicate of this bug. ***
Comment 31 Alexey Proskuryakov 2011-10-20 20:40:40 PDT
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>.
Comment 32 Ian 'Hixie' Hickson 2011-10-24 15:05:48 PDT
It is hoped Firefox will converge on this too, as the design was adopted based on discussions with a Gecko developer (bz).
Comment 33 Annor Mensah 2013-07-10 11:09:58 PDT
(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.
Comment 34 Lucas Forschler 2019-02-06 09:03:30 PST
Mass moving XML DOM bugs to the "DOM" Component.