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

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