155749 - Implement DOM3 Load/Save

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Comment 1

[rbs]

dup of bug 55394 comment #4.

Comment 2

[Boris Zbarsky [:bzbarsky]]

yeah, except I'm working on this and this is the bug I'm using to track the work
that needs to happen for a full implementation...

Comment 3

[Boris Zbarsky [:bzbarsky]]

.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I think 1.2alpha should be the timeframe we aim for most of the implementation,
and hopefully we can expose the interfaces in 1.3 (hoping the spec would be in a
final state by then).

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

nsbeta1+ for internal stuff. Like I said, we should expose the interfaces later
when the spec becomes final. 

Let's keep it in the 1.2alpha milestone to remind us of the work, and move it to
a later milestone (1.3?) to do the interfaces.

Comment 6

[Boris Zbarsky [:bzbarsky]]

hasn't happened yet, and alpha shipped..

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: Requirements document (Requirements.html)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: design document (Design.html)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: build system changes (except on mac) to make the existing stuff build.

Comment 10

[Boris Zbarsky [:bzbarsky]]

I don't know when I'll have time to get to this.

Comment 11

[tato]

Can't 'load()' be load from another domain? 

Comment 12

[Boris Zbarsky [:bzbarsky]]

No, for security reasons.

Comment 13

[tato]

is it specification? 
What security problem is there? 

Comment 14

[Boris Zbarsky [:bzbarsky]]

The problem that one site would be able to load and read another while using
your cookies and cached authentication tokens.

E.g. a random ad server could find out the balance in your bank account.

Comment 15

[tato]

Yes, I also know the problem. 
However, I think user has the right to choose ... about does it load? or
doesn't it load.

For example, it warns in a dialog, and it can choose. 
Or it sets up by pref... or Menu...

load is very useful for Web automation.

Comment 16

[Boris Zbarsky [:bzbarsky]]

The user almost certainly does not have enough information to make that choice.
 Users who think they do can disable the security check altogether via setting
the appropriate hidden pref.

> load is very useful for Web automation.

We don't want to make automating attacks too easy, though.

Comment 17

[Jerry III]

I agree that reading thirs party sites might pose a problem but are you going 
to require all web sites to host their DTDs and schemas localy so the DOM 
objects will be allowed to load them? Even in the case of standard ones, such 
as XHTML or SVG DTDs?

Comment 18

[Boris Zbarsky [:bzbarsky]]

That may be required, yes.  For standard ones, we may simply provide redirects
inside mozilla...

Comment 19

[tato]

>setting the appropriate hidden pref

Oh! nice. Where is it? 

>We don't want to make automating attacks too easy, though.

I of the feeling am the same as you. 
but wants only a few freedom... 

On Frames and Sub Windows , aother domain cannot be accessed. 
However, it can load.
If they cannot be read, I think that Web was boring. 

Test Example
http://202.215.116.61/~tato/addr2.htm

Comment 20

[Boris Zbarsky [:bzbarsky]]

No plans to work on this any time in the foreseeable future, so to default owner.

Comment 21

[Boris Zbarsky [:bzbarsky]]

No plans to work on this anytime soon.

Comment 22

[Hixie (not reading bugmail)]

(we should so just wontfix this. Is there anything this does that XMLHttpRequest
doesn't and that people really want?)

Comment 23

[Boris Zbarsky [:bzbarsky]]

Yes, this allows various ways of serializing a DOM and parsing a DOM.  People
use the DOMParser and DOMSerializer in Mozilla a good bit, so apparently there's
something that XMLHttpRequest just doesn't provide... ;)

Comment 24

[Hixie (not reading bugmail)]

Notwithstanding the uses which are just plain wrong [1], it seems that there is
basically just one DOMParser feature used from script, parseFromString(), and
one DOMSerializer feature used, serializeToString(). (And the baseURI feature of
the DOMParser seems to be only available from native code.)

Given that these features can all be provided using a grand total of two
methods, and that we can in fact make the API to use them *even simpler* than
what we have now [2], I see absolutely _no_ reason to propose that people use
the DOM3 Load and Save API, which is massively more complicated.


[1] I found one case that used a DOMParser to create a new Document with just
one node, and one case that used DOMSerializer to get a string that it then
passed to E4X to have reparsed into XML.

[2] I would suggest that instead of having to create a DOMParser and then invoke
a method on it, we just have createDocumentFromString() or parseXML() method on
the Window or DOMImplementation objects. Then you could just do:

   var myDoc = window.parseXML(s);

...instead of the two lines you need now (or the even more lines you'd need with
DOM3 LS). Similarly to serialise to XML we can just use document.toXMLString()
or some such, we don't need a new interface.

By "we" here I mean either the DOMWG or the WHATWG, and implemented by the
browser vendors instead of DOM3LS.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Well...

First off, I have no strong opinions on what API to use.  Here's how the
functionality stands off the top of my head:

Features provided by DOMParser/DOMSerializer/DOM3LS that people use that are not
present in your (corrected) model:

-Parsing/serializing to/from streams.  Certainly people parse from streams...  I
can see serializing to streams in a number of cases (eg when trying to produce a
POST data stream with multiple parts in a useful way without trying to create
all the MIME headers by hand).

Features provided bug DOM3LS that are needed but we don't provide anywhere:

-Reporting of XML parse errors (we have bugs on trying to do this in a sane way
for XMLHttpRequest and DOMParser).

Keep in mind that there's more to Mozilla than just the web aspect.  We want a
significant amount of the DOM3LS functionality (all except the filters part is
definitely needed, as far as I can see) for the platform aspect, basically.  We
could use the DOM3LS api for it, or we could use our own private little API
(DOMParser+DOMSerializer+whatever)...  But the functionality is still needed.

Comment 26

[Hixie (not reading bugmail)]

For our own platform, we *really* should not use DOM3LS. That API is horrendous.
DOMParser/DOMSerializer work quite well, and are already implemented and used; I
see no reason to change Mozilla-the-platform to use something else at this point.
If there are missing features, they should IMHO be filed as separate bugs on
improving those APIs.

For the Web side, I don't really understand how streams would work, and I think
if the API I mentioned earlier would be much better than DOM3LS.

DOM3LS is, with no offence intended to those involved, a committee-written mess.

Comment 27

[Boris Zbarsky [:bzbarsky]]

> For the Web side, I don't really understand how streams would work

Web content can create streams if it requests UniversalXPConnect privileges first.

Like I said, I'm not particularly tied to this API, but if we're going to
reinvent this wheel we would do well to actually design what our proposed API
will look like instead of doing it bit by bit.  Adding things like error
reporting to an existing API in a sane way is really hard.

Comment 28

[Hixie (not reading bugmail)]

Agreed.

Regarding error handling, is there really a use case for having more detailed
error reporting than the current Error exception? (Which already includes pretty
much everything the user needs to know, albeit without letting the script know
much about what exactly the error is.)

Comment 29

[Boris Zbarsky [:bzbarsky]]

At the moment, DOMParser does not report any XML well-formedness errors in any
useful way.  This has come up as an issue over and over again -- people need to
be able to tell what happened if their XML doesn't parse, and specifically they
want to get all the information in the message we'd normally output in
red-on-yellow when you load a malformed XML file.

Comment 30

[Hixie (not reading bugmail)]

I suggest filing that bug then. Implementing all of DOM3LS just to get error
handling in DOMParser seems a little over the top. :-)

Comment 31

[Boris Zbarsky [:bzbarsky]]

There are bugs filed on these various issues already.

Comment 32

[Hixie (not reading bugmail)]

(we should so just wontfix this)

Comment 33

[dan_500]

http://www.w3.org/TR/DOM-Level-3-LS/load-save.html

Comment 34

[Brett Zamir]

While I can appreciate that there might be other higher priorities, "won't fix" (as in ever) seems to be too strong for a browser claiming to adhere to web standards. Just because the functionality already exists in a non-standard way doesn't make a standard useless! Regardless of the perceived complexity (could multiple APIs be used?), DOM Level 3 is a standard, and besides being familiar to those who use it in other applications, it facilitates cross-browser solutions. And 20 votes is not that small of a small number from the bugs I've seen. Thank you.

Comment 35

[Boris Zbarsky [:bzbarsky]]

> DOM Level 3 is a standard

So are a lot of other things that we shouldn't be implementing...  I suggest you take a look at http://dbaron.org/log/2006-08#e20060818a

Comment 36

[Brett Zamir]

Attachment: Simple skeleton for JavaScript implementation workaround

A simple (and quite incomplete) JavaScript skeleton/wrapper with some examples implementing existing DOMParser and XMLSerializer functionality using basic Load/Save API (i.e., a simple workaround).

Comment 37

[Chris Carter]

Regarding cross-domain loading, do you have to send all the session information when a document is loaded?  And if that's necessary for some applications which load local files, can you restrict it to local files but still allow remote files to be requested?

Comment 38

[Brett Zamir]

Would it be possible to implement--for the web at least--just the current DOMParser and XMLSerializer features (perhaps just wrapping them internally like I did in JavaScript with my simple attachment) and forget about streams, or even the error handling you mentioned, etc.--just the functionality you already support? As a web developer, I'd like to be able to utilize these very basic features with an API which was not Mozilla-only (or Mozilla + IE, etc.). If other browsers implement the DOM 3 API in the future, of course such code should remain compliant into the future.

As taken from my comments in the attachment, this is all that is needed in DOM Level 3 for serialization:

  var ser = DOMImplementationLS.createLSSerializer();
  var str = ser.writeToString(document);

And while parsing to DOM is a bit more cumbersome...

  var lsInput = DOMImplementationLS.createLSInput();
  lsInput.stringData = '<myXml/>';

  var lsParser = DOMImplementationLS.createLSParser(1, null);
  var doc = lsParser.parse(lsInput);

These can easily be wrapped by the user in utility functions (I find a need to wrap the Mozilla API anyways, since I use these methods quite often).

It'd also be awesome if it could work with XML depending on an external DTD for entities.

Thank you very much!

Comment 39

[Michael A. Puls II]

I have a few requirements for loading an XML file.

1. In addition to http:, it must work for file: (so a local page can load a local xml file) without changing the loading code.

2. Must have a simple way to set a callback function that fires if the xml file is found and parsed without errors.

3. Must be async.

4. Must have a simple way to set a callback function that fires when there's an error.

5. Must not have to detect a parse error by checking the new document for a documentElement and or making sure that getElementsByTagNameNS("http://www.mozilla.org/newlayout/xml/parsererror.xml", "parsererror").length === 0. A parse error should be part of #4.

I can hack that together with XMLHttpRequest like this:
<http://shadow2531.com/opera/testcases/xhr/loadXMLFile.html>
<http://shadow2531.com/opera/testcases/xhr/loadXMLFile.js>

, but that's not very straightforward, fails #2, #4 and #5 and MS doesn't allow XHR to work for file:.

I can use document.load(), but that fails #5 and #4, is an old version of load and save, not supported in Safari and the async version fails in Opera (including how exceptions are thrown).

However, with DOM3 LS, I can do this:

var parser = this.createLSParser(this.MODE_ASYNCHRONOUS, null);
parser.domConfig.setParameter("error-handler", function(err) {
    alert(err.message);
});
parser.addEventListener("load", function(e) {
    alert(e.newDocument);
}, false);
parser.parseURI("file.xml");

, which is great, simple, intuitive, straightforward and way easier than XHR even.

Now, Opera is the only one that supports it. (The load event never fires in Opera right now though because of a bug. The synchronous mode, which causes parseURI to just return the doc works fine though.)

But, it'd be lovely if all browsers supported Load and Save.

Further, wrapping those few lines in DOMImplementation.prototype.loadXMLFile, makes it even better.

Now, there's a lot more to Load and Save than that (like writeToURI), but the above is the main part I'd like.

Comment 40

[Boris Zbarsky [:bzbarsky]]

I don't see how getting all browsers to implement Load&Save is easier for your use case than getting them to improve XHR.  For example, #5 will be fixed once we implement the current draft XHR spec; a readystate handler will do most of #2 and #4 for you, and IE adding XHR for file:// is much more likely than IE implementing Load and Save.

Comment 41

[Michael A. Puls II]

(In reply to comment #40)
> I don't see how getting all browsers to implement Load&Save is easier for your
> use case than getting them to improve XHR.

O.K.

> For example, #5 will be fixed once
> we implement the current draft XHR spec;

Cool.

> a readystate handler will do most of
> #2 and #4 for you,

Yeh, I can make that work using readyState by wrapping things etc. XHR should support 'load' and 'error' events also though. Then, that would solve that part.

> and IE adding XHR for file:// is much more likely than IE
> implementing Load and Save.

I reported the issue for IE fwiw. Not sure what they'll do, but maybe they'll fix that.  The XHR spec doesn't really cover "file:" though, so they probably won't do anything unless it's in the spec. I really think the browser should make "file:" give a status of 200 when the file is found and readable to be consistent with http (so you don't have to have extra code conditions for file:)

Load and Save does it exactly like I want. If XHR can be extended to also do the same as an option, then yeh, that'd be acceptable. In fact, I don't see how making XHR also support onload and onerror (in addition to onreadystatechange) would interfere with anything.

But, also want to make sure saving to file: from a file: page works with XHR across the board.

Comment 42

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to Hixie (not reading bugmail) from comment #32)
> (we should so just wontfix this)

Indeed.