Bug 4054 – XML/XSLT pages fail to run JavaScript XMLHttpRequests

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Vicki Murley]

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.

[Michael Sinz]

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

[Michael Sinz]

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

[Michael Sinz]

May be related with bug #4359?

[Michael Sinz]

Could this have been fixed with the fix for bug 5219?

[Alexey Proskuryakov]

Yes, this also works correctly for me in ToT (text style is different, but that seems to be covered by bug 
4358).

[Michael Sinz]

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

[Alexey Proskuryakov]

Yes, the test page is now rendered correctly in ToT.

[Michael Sinz]

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)

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

It looks fine in TOT.  I've sent back the original radar.  Closing this one.