Last Comment Bug 621276 - Script tag onerror event does not fire if src attribute points to non-existing file://
: Script tag onerror event does not fire if src attribute points to non-existin...
Status: RESOLVED WORKSFORME
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 646214 (view as bug list)
Depends on: 282432 789856
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-24 01:32 PST by st777
Modified: 2012-11-10 05:51 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase from bug 646214 (381 bytes, text/html)
2012-04-04 16:35 PDT, Nickolay_Ponomarev
no flags Details

Description st777 2010-12-24 01:32:16 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

I'm attempting to inject a new script tag dynamically into a head element using DOM appendChild. When I inject a script tag that points to a non-existent file, onerror event of the injected script tag does not fire.

Reproducible: Always

Steps to Reproduce:
1. Create a new script tag: var newScript = document.createElement("script");
2. Bind an event to new script element: newScript.onerror = function() { alert('error!');}

3. Set src attribute of new script element to a bogus(non-existent) file: newScript.src = "foo.js";

4. Append new script element to head element: document.getElementsByTagName('head')[0].appendChild(newScript);
Actual Results:  
onError handler in step 2 does not fire

Expected Results:  
onError event must fire to let me know that something is wrong with loading a file

Test script is running locally on a desktop machine and not from a hosted location. Not sure if that makes a difference.

This behavior works correctly in all major browsers such as chrome, safari, IE 7-9
Comment 1 Boris Zbarsky [:bz] 2010-12-24 10:18:08 PST
> Test script is running locally on a desktop machine and not from a hosted
> location. Not sure if that makes a difference.

It does.  For file:// URIs this is a known issue.

This is similar to bug 269125, and I was pretty sure we had a duplicate of this for <script> already...

Ms2ger, want to fix?
Comment 2 :Ms2ger 2010-12-25 07:23:26 PST
Bug 608809?

Last time I looked at our script execution code (or the spec, for that matter), it looked sufficiently scary not to attempt a fix. I could try if you pointed me at the place I'd need to patch, though.
Comment 3 Boris Zbarsky [:bz] 2010-12-25 10:09:12 PST
> Bug 608809?

That bug wfm.

> I could try if you pointed me at the place I'd need to patch, though.

We need to fire an error event if AsyncOpen on the script's channel returns failure.
Comment 4 Nickolay_Ponomarev 2012-04-04 16:33:20 PDT
*** Bug 646214 has been marked as a duplicate of this bug. ***
Comment 5 Nickolay_Ponomarev 2012-04-04 16:35:17 PDT
Created attachment 612394 [details]
testcase from bug 646214
Comment 6 douglyuckling 2012-08-01 10:51:41 PDT
As more and more people are unit testing their JavaScript (and often using flat file:// URLs), this bug is pretty annoying.  There is some discussion of workarounds at Stack Overflow: http://stackoverflow.com/questions/4150430
Comment 7 O. Atsushi (Torisugari) 2012-11-09 20:39:19 PST
JFYI, according to Asqueella's testcase, WFM.
Comment 8 Boris Zbarsky [:bz] 2012-11-09 22:01:19 PST
This got fixed in bug 789856, I would bet...

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