This bug is also in Radar as <rdar://4096841> It seems that if I make a page that is generated via XML/XSLT, any JavaScript in that page fails to even start a load of an XMLHttpRequest object. Test #5 at http://svn.sinz.com:8000/browser-tests/index.html shows this in detail. It is a combination of Test #1 (which uses XMLHttpRequest to load the banner area of the page) and Test #2 (which uses XML/XSLT to build the main body of the page) From the output of the JavaScript, it looks like everything went wrong. What really seems to be happening in the test setup is that it is loading the JavaScript from the wrong URL!! My server logs show that it is requesting /browser-tests/index.js rather than /browser-tests/test5/index.js Now, when I load the test page directly and not within the frame, this problem goes away but the XMLHttpRequest still does not seem to run correctly. In this case, everything looks fine, even the xml.send(null) worked. However, not one callback was made (quite failure). I saw nothing in the JavaScript console in Safari. If you note, the XML/XSLT should produce (module some text identifying the test) the exact same result as the Test #1 case. In fact, I have verified that with both Mozilla and IE plus with manual XSLT processing (xsltproc). This is preventing the Insurrection source control interface from working correctly in Safari. I already worked around the lack of XPath/document() function support, but I must have access to the XMLHttpRequest(). <GMT22-Apr-2005 18:43:37GMT> So, I am confused as to what is going on. With Test #5 failing, it looks like Safari is somehow causing the XMLHttpRequest object to fail (due to security checks due to the wrong context as can be seen in the wrong links in Test #2?) To me, this looks like the URL context of the XML/XSLT page is somehow of a different state than a normally loaded HTML page.
So, this really should be two bugs - one due to frames and relative URLs/styles & XML/XSLT (see bug #4358) and the other having to do with the XMLHttpRequest being blocked (this bug). Since this bug report title is about XMLHttpRequests, I figured that it should remain as such and that the new bug report will be about the frames. In order to remove the frameset from the picture, go directly to the page http://svn.sinz.com/browser-tests/test5/index.xml This page is an XML/XSLT page that generates HTML that should be (almost) exactly like the reference page at http://svn.sinz.com/browser-tests/test5/ref.html. (The reason for the almost is that some spaces may be different in the output of the XML/XSLT vs the static HTML file - but there should be no material difference) As can be seen, the XML/XSLT generated page does not load the banner via the XMLHttpRequest object albeit it should have. What seems to have happened is that the request, which is a relative path, is somehow relative to some internal URI due to the fact that the actual HTML was generated via the XML/XSLT transformation. (BTW - It would be good to have the URL change to not be at port 8000 since the server now is on port 80 - well, actually, it is a completely different server - I can't change this since Vicki entered the bug from the Apple system on my behalf and did not give me ownership of the bug.)
Should this really be in JavaScript? The reason I ask is that the page with the JavaScript that runs without XML/XSLT (see http://svn.sinz.com/browser-tests/test1.html which is all HTML/JavaScript/XMLHttpRequest and it works just fine) My guess is that this is due to some behavior of the XML/XSLT transform into the HTML page and resulting internal structures and not the JavaScript engine. Again, I can not change this since I am not the submitter of record. BTW - The URL for this bug should be http://svn.sinz.com/browser-tests/test5/index.xml
May be related with bug #4359?
Could this have been fixed with the fix for bug 5219?
Yes, this also works correctly for me in ToT (text style is different, but that seems to be covered by bug 4358).
Could you please try the test page again? I think the problem was due to the XSLT generated page not defining a <!doctype...> and Safari does a slightly different rendering mode for the page. (Different than what Mozilla and IE do, at least) The test pages now specifically define a <!doctype...> in the XSLT output. (The HTML pages already had a doctype.)
Yes, the test page is now rendered correctly in ToT.
Ok, so the only question now is if the default behavior is wrong - but I would contend that that is a minor nit. When given a complete HTML document that includes a doctype from an XSLT transform, the rendering is now correct. While I was the initial reporter of this bug, that was back when it was in Radar so I can not make any changes to the status. BTW - I would also like to update the URL to not include port 8000 as that was on my older test server setup and I would like to not need to continue to have a redirect set up for that URL. (Just remove the ":8000" from the URL)
Created attachment 4511 [details] ToT rendering This bug should probably be closed now, but I have noticed another discrepancy between the expected and actual rendering - the text "Test #5" is positioned slightly differently. Taking an opportunity to attach a screenshot for further analysis; might warrant an additional report.
It looks fine in TOT. I've sent back the original radar. Closing this one.