842204 - Error-location pointers point into whitespace past truncated error lines

Status: RESOLVED DUPLICATE of bug 1282481

(DevTools :: Console, defect)

Description

[Zack Weinberg (:zwol)]

Attachment: screen shot of problem

Noticed this while trying to reproduce bug 840451.  If the error console is narrow, as in the attached screen shot, long error lines will be ellipsized at both ends, but we make no effort to keep the actual position of the error visible, and the green arrow pointing to the error position is not ellipsized, leaving it pointing off into blank space.

(My usual informant tells me this has been the case for JS syntax errors for years and years now.)

Comment 1

[Philip Chee]

I can confirm.

Comment 2

[Brian Grinstead [:bgrins]]

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.

Comment 3

[Zack Weinberg (:zwol)]

The phenomenon in the Browser Console is different enough that I'm going to file a new bug, but this is your reminder that if you want to mass-close a set of bugs, it is *your responsibility* to check *every single one* and find out whether it's still relevant.  Do not push that work onto bug reporters.

https://www.jwz.org/doc/cadt.html

Comment 4

[Zack Weinberg (:zwol)]

Please acknowledge that you will do the work of checking all the other bugs you just mass-closed.

Comment 5

[Zack Weinberg (:zwol)]

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.)

Comment 6

[Zack Weinberg (:zwol)]

OK, it turns out that I *didn't* have to do that in two steps after all.  Yay bugzilla.

This particular bug is superseded by bug 1282481.

bgrinstead, I still want to hear you confirm that you will, yourself, check each of the bugs you inappropriately closed, and close only those that are genuinely no longer relevant.

Comment 7

[Brian Grinstead [:bgrins]]

These are bugs in a component that's been removed from tree - they weren't closed because of a refactor or just because they are old.  Both the code and the functionality that these bugs were filed against no longer exist.  The removal and the mass-closure of bugs were discussed publicly prior to this happening on dev-platform.