<script defer> blocks additional resources in XHTML documents
Reported by
anthonyr...@gmail.com,
May 11 2016
|
|||||
Issue descriptionUserAgent: 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:
,
May 16 2016
,
May 16 2016
,
May 17 2016
,
May 18 2016
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.
,
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 |
|||||
Comment 1 by mmenke@chromium.org
, May 12 2016