Err, I small detail I, uhh, ahem, forgot to mention. I wasn't testing against Safari. :^) I was testing against the WebKit nightly build. --Paul Andrew Eberhard wrote:
Hi Paul,
Thanks for responding (and sorry my post was inadvertently directed only to Eric). I did run into the problem that you mentioned and I patched sarissa.js to do exactly what you suggested (I used "temp"). Most of the sarissa test cases now run successfully (very good news), but the problem I mentioned is actually a separate issue.
When creating an XML document, sarissa assumes that the output of document.implementation.createDocument implements a method called "load." This allows the XML document to load XML from an XML file using a standard URI (i.e. file://, http://, and relative paths). As far as I can tell, this method is not implemented in Safari causing sarissa to break whenever the SarissaDocument.load method is used.
Technically, Sarissa goes a step further for browers that implement document.implementation.createLSParser by overriding the default document.implementation.createDocument.load method with a user defined function that makes use of the functionality described here (specifically document.implementation.createLSParser.parseURI): http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html I am not sure I understand why this approach is used for some browsers (document.implementation.hasFeature('LS', '3.0') == true), perhaps it performs better than the document.implementation.createDocument.load method. Nevertheless, FireFox will work just fine with either but sadly Safari won't do either.
Technically, Sarissa could be updated to use XMLHttpRequest in order to provide SarissaDocument.load functionality to the web developer, but the more I investigate that approach, the more it resembles a crude substitute for implementing the load method on document.implementation.createDocument.
I guess I'm not sure whether or not this is a bug, an oversight, or a deliberate omission in Safari. I'm also not certain what to ask for (document.load or LSParser support). Once I determine this, I should be able to either convince the folks at Sarissa to modify their code, enter a bug report on Safari (still waiting on my BZ enrollment email...), or just hack Sarissa myself to implement SarissaDocument.load for Safari alone using XmlHTTPRequest.
Many thanks! Andrew
On 03.01.2006, at 01:35, Paul Everitt wrote:
Andrew Eberhard wrote:
Hi Eric, Well, I'm getting underway with Safari-enabling my AJAX project [using the latest nightly build ;-) ] and I've run into a problem that seems to be "as designed" but I wanted to run it by everyone first. Basically, Document.load is not supported in Safari. I assume that I can use XMLHttpRequest instead, but http://bugzilla.opendarwin.org/show_bug.cgi?id=5411 led me to think that there might be reason to enter a bug on Document.load support. Since Sarissa currently relies on Document.load for SarissaDoc.load, I wasn't sure if bug #5411 was intended to include Document.load support in Safari or if the folks at Sarissa should be asked to update it to work with Safari's XmlHttpRequest approach. There is a bit of prior research on this subject at http://www.xs4all.nl/~zanstra/inTec/safariIdea.htm.
Hi Andrew. The Sarissa folks are taking a look at it. It's actually possible to work around the bug, I believe.
Here is what triggers the bug:
var oldDoc = document.implementation.createDocument("", "", null);
(Note: This is against the Sarissa CVS HEAD.)
Creating a document with a real node name for the document element, though, works:
var oldDoc = document.implementation.createDocument("", "foo", null);
Hmm, come to think of it, this works as well:
var oldDoc = document.implementation.createDocument("", null, null);
Anyway, my guess is that your application can be made to work with a patched Sarissa. I *think* (but I'm not sure) that the qualified name (2nd arg) should either be a real node name or null. In which case, WebKit is right and we need to change Sarissa.
--Paul
------------------------------------------------------------------------
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev