New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 614855 link

Starred by 1 user
Status: Fixed
Owner:
█ sigbjo...@opera.com
Email to this user bounced
Closed: May 2016
Cc:
█ sigbjo...@opera.com
kouhei@chromium.org
neis@chromium.org
hirosh...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Injecting a <script> with async=false that subsequently errors, causes the onload event to never be dispatched

Project Member Reported by eroman@chromium.org, May 25 2016 
See attached simplified test.

Reproducing this involves:

 * Have at least one <script async=false> that FAILS
 * Queue up a <script> that doesn't fail after this
 * Must explicitly set async=false or won't reproduce

I am able to reproduce on Chrome 50, however it does not reproduce on the current Canary channel.

So this may have already been fixed.

But since I couldn't find the corresponding bug, would like to confirm that the reason it works on Canary isn't accidental.
onload_repro.html
1.2 KB View Download
real.js
11 bytes View Download

Comment 1 by sigbjo...@opera.com, May 26 2016 

Thanks, don't want to have latent problems in this area.

This one was addressed as part of issue 581425; a crash fix, but prior to it the pending in-order script queue wouldn't be drained & scheduled for execution across script load failure notifications. Verified locally to reproduce with it reverted.

We don't have fast/dom/HTMLScriptElement coverage for this case; adding the testcase.

Comment 2 by toyoshim@chromium.org, May 26 2016

Owner: sigbjo...@opera.com
Status: Assigned (was: Untriaged)
I was running a bisect, and noticed this issue was fixed in (381275,381281].
That exactly contains sigbjornf's fix.

sigbjornf, can I assign you to this bug for adding the testcase?

Comment 4 by sigbjo...@opera.com, May 27 2016

Status: Fixed (was: Assigned)
►

Sign in to add a comment