Bug 80045

Summary:	SPDY 3 spec fails to render in Webkit
Product:	WebKit	Reporter:	William Chan <willchan>
Component:	XML	Assignee:	Nobody <webkit-unassigned>
Status:	NEW
Severity:	Normal	CC:	abarth, ap, eric
Priority:	P2
Version:	528+ (Nightly build)
Hardware:	All
OS:	All

William Chan

Reported 2012-03-01 13:49:06 PST

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.

Attachments
Add attachment proposed patch, testcase, etc.

Eric Seidel (no email)

Comment 1 2012-03-01 13:58:43 PST

Eric Seidel (no email)

Comment 2 2012-03-01 16:00:12 PST

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)

Comment 3 2012-03-01 16:01:04 PST

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

Comment 4 2012-03-01 16:04:51 PST

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

Eric Seidel (no email)

Comment 5 2012-03-01 16:13:05 PST

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)

Comment 6 2012-03-01 16:13:42 PST

(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

Comment 7 2012-03-02 14:21:51 PST

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)

Comment 8 2012-03-02 14:24:19 PST

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.

Note You need to log in before you can comment on or make changes to this bug.