Bug 80045 – SPDY 3 spec fails to render in Webkit

• Status: NEW
• Component: XML

[William Chan]

http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml renders successfully in Firefox, but only shows a blank page in Chrome and Safari.

[Eric Seidel (no email)]

There are a bunch of errors in the console.  It's unclear which (if any) of these would be causing the XSL to fail like this:

Failed to load resource: the server responded with a status of 404 (Not Found)
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.1738.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.1950.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.2285.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
Unsafe attempt to load URL http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml from frame with URL http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml. Domains, protocols and ports must match.
http://mbelshe.github.com/SPDY-Specification/rfc2629.dtdFailed to load resource: the server responded with a status of 404 (Not Found)

[Eric Seidel (no email)]

I suspect the preload scanner may be generating those spurious warnings.  It's not clear why this page would even be trying to load reference.RFC.0793.xml , etc. since those are just text entity replacements.

[Eric Seidel (no email)]

The 404 (which could be part of the bug) is caused by "rfc2629.dtd" in the entity declaration.  Which is an error, but shoudl be non-fatal?

[Adam Barth]

I doubt it's the preload scanner.  We need to look in the debugger to see what the problem is.

[Eric Seidel (no email)]

XSLT handling is kinda crazy in WebKit.  We re-parse the document (and stylesheet) with libxml, pass it off to libxslt, and then serialize back to text, re-parse with webkit and finally display the result.  To add to the fun we convert from WebKit's utf16 strings to utf8 for libxml/xslt as well. :)

We parse the whole document, record that we saw an XSLT transform:
http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser/XMLDocumentParser.h#L192
save off the text-source of the XML:
http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser/XMLDocumentParser.cpp#L119
http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp#L1262

The normal loader system:
http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedXSLStyleSheet.cpp
loads the XSL stylesheet, then it's parsed:
http://trac.webkit.org/browser/trunk/Source/WebCore/xml/XSLStyleSheetLibxslt.cpp#L132

The Document itself actually drives the application of the stylesheet:
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.cpp#L4277
I suspect that FIXME might lead to understanding better what's going on here. :)

I'm happy to explain further if someone is interested in looking into this.

[Eric Seidel (no email)]

(In reply to comment #4)
> I doubt it's the preload scanner.  We need to look in the debugger to see what the problem is.

Oh, I don't mean that the preload scanner would be causing this bug.  But rather that it might be causing the extra log messages about urls which are never used as loads. :)

[William Chan]

I've tried running this in the debugger and have found that it leads to variance in whether or not http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.cpp#L4273 gets called. Sometimes the transformToString() call succeeds and sometimes it doesn't. I've actually had the page render correctly at some points. It seems like running it in the debugger leads to some timing changes that may cause the transform to succeed. I will look into it some more next week, but that's where I am for now.

[Eric Seidel (no email)]

I wonder if the XSL sheet has load dependencies and if we're not correctly waiting for them.  I know we have some code to handle subresource dependencies in xml processing instructions, but who knows if such code actually works.