248801 - Javascript console needs to report source URL consistently

Status: RESOLVED DUPLICATE of bug 11240

(Core :: DOM: Events, defect)

Description

[Craig]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040616

Most errors are reported in the JS console with a source URL and line number.
Some are not. If you are browsing with large numbers of tabs/windows open, then
get a problem with a page, then have a look at the JS console, it may be
impossible to know whether the errors that are logged are of any relevance or
not when they have nothing to identify where they came from.

Reproducible: Always
Steps to Reproduce:
1. Do lots of web browsing.
2. Look at JS console.

Actual Results:  
Most items logged with URL and line number. Others logged such as:
"Error: this.u has no properties"
or
"Error: mOut is not defined"


Expected Results:  
Give the same error, with a URL to say where it came from.

Comment 1

[timeless]

this is not the console's fault.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Craig]

I don't believe "this is not the console's fault" is a very meaningful or
constructive comment. Any (decent) software should log what it was doing when an
error occurred. It should be possible for the console to be given the
information about the source of the javascript file which it is reporting on.

Comment 4

[Alex Vincent [:WeirdAl]]

Craig:  part of the problem is that the steps to reproduce are very vague.  We
need specific testcases to reproduce specific bugs.

I could browse around all day on some websites and never see what you're
reporting.  Or I could browse around on a couple websites and get thousands.  I
can't tell which.

Please, give us a specific testcase to produce one error message without a
source URL.  That will tell us if this is a bug we already have on file, or if
this is a new one.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The point timeless made was that the bug is in the code that logs a message to
the console, not in the console itself.

Given that this bug has no steps to reproduce, I can't tell which of the known
cases where we don't have a URI to tell the console this bug is about, so
marking invalid....

Comment 6

[Craig]

(In reply to comment #5)
> The point timeless made was that the bug is in the code that logs a message to
> the console, not in the console itself.

Whether the console can work out what URL it is reporting on or whether it has
to be told explicitly by the reporting routine is a matter of code structure.
Whose "fault" it is doesn't make it more or less a bug.

> Given that this bug has no steps to reproduce, I can't tell which of the known
> cases where we don't have a URI to tell the console this bug is about, so
> marking invalid....

You should always have a URI to tell the console about and should always tell
it. That's exactly the point. If you report a javascript error, which must have
come from code from _some_ URL, and don't report that URL to the user, the
reporting of the error itself is useless.

It is inherently hard to provide test cases. If we browse for a day, check the
console, and find some error messages with no URL listed, it is impossible to
know where the error occurred, so we can't tell you where the problem occurred.
What's more, test cases for such a bug are a bad idea. All routines which report
errors to the console should be forced to provide the relevant URI. This is a
matter of correct coding, not fixing a few test cases at random and assuming
you've achieved something.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Craig, the point is that we have several known instances where we have no URI. 
This bug is a duplicate of one of them with very high (0.99 or higher)
probability.  But since you gave me no indication WHICH bug I should mark this
duplicate of (e.g. you might have pasted in the error message you got, but you
didn't even bother to do that), I'm going to mark this bug invalid because there
is nothing we can do to address it as filed.  Bugs on specific instances of not
having a URI can be fixed; a bug like "there should always be a URI" is
unfixable in principle, since we might not even control the core reporting the
error -- it might be in an extension you have installed, or in a plugin, etc.

So re-marking this invalid.  Please don't reopen this bug again.

Comment 8

[Craig]

(In reply to comment #7)
> I'm going to mark this bug invalid because there
> is nothing we can do to address it as filed.

Sure there is. ... and it's now been done. See bug bug 312630.

> Bugs on specific instances of not
> having a URI can be fixed; a bug like "there should always be a URI" is
> unfixable in principle, since we might not even control the core reporting the
> error -- it might be in an extension you have installed, or in a plugin, etc.

In that case, you can put in something like "Pointless error report from
non-compliant plugin 'blah'" where the URI should be.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Sure there is. ... and it's now been done. See bug bug 312630.

That handles cases that use nsIScriptError.  Plenty of console service consumers
use nsIConsoleMessage, however.

> you can put in something like "Pointless error report from
> non-compliant plugin 'blah'"

No way to tell who's making the error report.  See the nsIConsoleService api.

Comment 10

[Craig]

Here's a trivial example!
If the onload() function isn't defined, it doesn't report the URL it was called from.

Comment 11

[Craig]

Attachment: Simple page to generate URL-less javascript console error

Run this and javascript console reports:
"Error: someonloadfunction is not defined"

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 11240 ***