302252 - Console Filter extension broken by fix for bug 301398

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: Error Console, defect)

Description

[Simon Bünzli]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+

The fix for bug 301398 breaks Console Filter and similar extensions (JS Console
Filter, All-In-One Sidebar) by renaming one attribute in consoleBindings.xml
("url" -> "href"). This happened most probably because of consistency and
unaware of the existing, now broken dependency.

Obviously the fix is simple (I've already updated Console Filter), but instead
of having the authors of the other extensions also fix their code, I propose to
revert that part of the change (as a sign of respect for backwards compatibility
;-)).

Reproducible: Always

Steps to Reproduce:
1. Install JS Console Filter from
https://addons.mozilla.org/extensions/moreinfo.php?id=739
2. Visit http://www.google.com/
3. Open the JavaScript Console and try to filter all error messages from Google.

Actual Results:  
Nothing happens.

Expected Results:  
All other messages are hidden.

Comment 1

[Simon Bünzli]

Attachment: retain url attribute for compatibility

Setting the url attribute is sufficient for maintaining backwards
compatibility.

Additionally, I'd like to add one more attribute for the message's category
(allowing the filtering of e.g. all CSS errors through a simple CSS rule). Can
this just be done in this bug here, as well?

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I like adding category, but I'm not sure that backwards compatability is a good
enough reason to add a duplicate attribute.  The href change was made for bug
301398 for accessibility -- elements with a href attribute are magically
understood by the a*ty framework to be links and can be handled specially. 
Putting both "url" and "href" is just going to confuse someone who has to
maintain this code later on, I think.

Comment 3

[Simon Bünzli]

Filed bug 306223 for the category bit. As for the backwards compatibility bit, I
drop my request for the sake of code clarity, since it's just a one line fix for
the few extension authors which were relying on this, as well.