New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 611136: <script defer> blocks additional resources in XHTML documents

Reported by anthonyr...@gmail.com, May 11 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.36 Safari/537.36

Example URL:
https://whatbox.ca/bugs/chromium-defer-xhtml

Steps to reproduce the problem:
1. Place a number of <script defer src="..."> tags in the head of a page
2. Change the content type to application/xhtml+xml
3. Observe that all <script> tags are now blocking

What is the expected behavior?

What went wrong?
<script defer> should not block the download of additional resources, the same way it doesn't with a html content type.

Did this work before? N/A 

Chrome version: 51.0.2704.36  Channel: beta
OS Version: 
Flash Version:
 

Comment 1 by mmenke@chromium.org, May 12 2016

Components: -Internals>Network Blink>HTML>Script Blink>Loader

Comment 2 by kouhei@chromium.org, May 16 2016

Owner: kouhei@chromium.org

Comment 3 by kouhei@chromium.org, May 16 2016

Components: Blink>HTML>Parser

Comment 4 by kouhei@chromium.org, May 17 2016

Status: Started (was: Unconfirmed)

Comment 5 by kouhei@chromium.org, May 18 2016

Status: WontFix (was: Started)
XHTML documents are handled by XMLDocumentParser, where as HTML documents are handled by HTMLDocumentParser. They are totally different code path.

HTMLScriptElement -> ScriptLoader -> ResourceFetcher all handles this correctly.
The problem is that XMLDocumentLoader doesn't support deferred scripts at all.
XMLDocumentParser::endElementNs() force executes any scripts synchronously and pauseParser() until the script is ready.

Our long term plan is to deprecate XMLDocumentParser and have XHTML documents all handled by HTMLDocumentParser.

Comment 6 by anthonyr...@gmail.com, May 18 2016

Fair enough, that's a reasonable choice.

I'd say though that if bugs in the XMLDocumentParser aren't going to be addressed, the application/xhtml+xml encoding should be removed from the Accept request header.

It feels like both a reasonable first step toward deprecating the XMLDocumentParser and ensures that websites which uses the Accept header to determine the Content-Type response header will begin the transition to HTMLDocumentParser for Chrome already.

I look forward to your thoughts.

Sign in to add a comment