467439 - JavaScript: error details missing in arguments to window.onerror when script is loaded from different host name than web page.

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Brian Harper]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

Firefox supports window.onerror for handling JavaScript errors. When the function is called, the arguments include the error message, file name, and line number for the script that resulted in the error. However, if our <script> tags point to .js files from a different host name than the web page was served from, the error message is always reported as simply "Script error", and the line number as 0. In addition, the .caller property of the function specified for window.onerror is null, making it impossible to determine the call stack for the error.

Is this a security feature? It's not clear to me why the onerror function would still be executed, but be missing the key details to aid in debugging it. If it is intended behavior and closes a security hole of some sort, it seems to me that it should only behave this way if the top-level domain differs. For example, if static.foo.com serves up the .js files that are referenced from a page served by dynamic.foo.com, it should not be subjected to this additional security. In our case, we are trying to deliver our static content via a content distribution network while our central servers process dynamic requests, and this is facilitated through the use of different host names.

Reproducible: Always

Steps to Reproduce:
1. Access a web page at a.foo.com that includes <script> tags that download a .js file from b.foo.com. The web page should include JavaScript that sets window.onerror = handleError; The handleError function is defined in the .js file. The function outputs the arguments passed in.
2. Simulate a javascript error of some kind, for example reference a property that does not exist.


Actual Results:  
The output of the error specifies the error as "Script error" and the line number as 0.

Expected Results:  
The output of the error should include a descriptive error message and the actual line number that the error occurred on.

This bug makes it hard for us to debug javascript issues, as we have no way of knowing what went wrong and where in our code the error occurred. Our application will send client error messages up to our server so we can resolve bugs quickly, but since we implemented our change to use different host names, we've lost this visibility for Firefox users. We don't have a problem with IE, as it doesn't behave in this fashion.

Comment 1

[Nochum Sossonko [:Natch]]

This should have been fixed in 3.1, please test this on current nightlies and reopen if it's still a problem.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Actually, bug 440595 was about file:// URIs only.  This bug is not about file:// URIs.

> Is this a security feature?

Yes.  In fact, this bug is invalid.  See bug 363897 for the reasons.  Your top-level suggestion isn't workable in practice, since independent sites may be using the same top-level domain in many cases...

Comment 3

[Daniel Veditz [:dveditz]]

Note that the real error is available in the error console for debugging purposes, it's just not available to the potentially malicious page.