the arrow that shows where the error is is sometimes in a wrong place (using backslashes)



Toolkit Graveyard
Error Console
17 years ago
2 years ago


(Reporter: Julien Wajsberg, Unassigned)





(1 attachment)



17 years ago
When there is an error, the arrow soemtimes shows incorrectly. I think it's
especially related when there are some backslashes (\) in the javascript code

Reproducibility : every time

Steps to reproduce :
1.Open the URL mentioned
2.Open Javascript Console
3.Click Clear to remove all older errors
4.Click on bad1 bad2 bad3 bad4
5.Look in the Javascript Console

Actual results :
With Mozilla Linux, the error is badly reported (arrow is under the bad caracter)
With Mozilla Windows, the error is badly reported only with bad4.

Expected results :
The arrow should be under the faulty '.

Comment 1

17 years ago
Created attachment 65518 [details]

Comment 2

17 years ago
Confirmed. (Build ID: 2002 01 21 03/Win98).


Comment 3

17 years ago
Duping to a bug that got some attention.

*** This bug has been marked as a duplicate of 124332 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 4

17 years ago
I don't think it's the same bug, since the Javascript Console correctly shows
where the error is most of the time, although it uses a scaled font.
Resolution: DUPLICATE → ---
I can see it here (2002073022, Linux), so this is at least a real bug (and not
that dup)
Ever confirmed: true


10 years ago
Product: Core → SeaMonkey
Assignee: hewitt → nobody
QA Contact: jrgmorrison → error-console

Comment 6

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

9 years ago
Confirm that the problem still exists on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1pre) Gecko/20090614 SeaMonkey/2.0b1pre

In addition all four errors are problematic on WinXP rather than only bad4 as described in Comment 0
Component: Error Console → Error Console
Product: SeaMonkey → Toolkit
QA Contact: error-console → error.console
Hardware: x86 → All
This should be fixed by the patch in bug 305206, setting dependency.
Depends on: 305206
The newer WebConsole doesn't show anymore where there is an error. I don't know if I should call this a win, but at least this makes this bug INVALID, I guess ?

Comment 10

2 years ago
(In reply to Julien Wajsberg [:julienw] from comment #9)
> The newer WebConsole doesn't show anymore where there is an error. I don't
> know if I should call this a win, but at least this makes this bug INVALID,
> I guess ?
This bug isn't invalid because this bug is about the Toolkit Error Console, not the Devtools Web Console. And the TK Error Console is used by other applications like Thunderbird, SeaMonkey, and Instantbird - all of which live in the comm-central repository.
The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed.  If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.
Last Resolved: 17 years ago2 years ago
Resolution: --- → WONTFIX
I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.

If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid.  Do not push that work onto the bug reporters.

(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify.  But that is the ONLY situation where it is okay.)

(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works.  Apologies for the extra bugspam.)
Component: Error Console → Developer Tools: Console
Product: Toolkit → Firefox
Resolution: WONTFIX → ---
SyntaxError: missing ) after argument list
I think this qualifies as WFM.
Last Resolved: 2 years ago2 years ago
Resolution: --- → WORKSFORME
Component: Developer Tools: Console → Error Console
Product: Firefox → Toolkit


2 years ago
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.