370513 - User style for XUL with an attribute selector on an attribute with a capital letter doesn't work

Status: RESOLVED DUPLICATE of bug 282328

(Core :: CSS Parsing and Computation, defect)

Description

[Jason Barnabe (np)]

Any user style that uses an isDisabled attribute selector doesn't work. A real-world example is the following, which should hide disabled extensions in the Firefox add-ons dialog:

#extensionsView richlistitem[isDisabled="true"] { display: none !important; }

Looking in DOMI, the element doesn't even show the user style in the CSS style rules view, so it's not a matter of the XUL not being able to change style on the fly like in bug 320060 or bug 320072.

Any other attribute selector, such as "hidden" or "blocklisted" or "compatible",  works as it should.

Another wrinkle to this can be found by using the Stylish extension https://addons.mozilla.org/firefox/2108 . A quick overview of how Stylish works: in post-bug 335689 builds (Fx 3.0a and later), Stylish solely uses the stylesheet service to apply its styles. In pre-bug 335689 builds (Fx 2.0 and earlier), Stylish registers the style in the stylesheet service but also tosses html:links in every document currently open to instantly apply a style. In the case where the style is applied via html:link, this user style *works*.

In summary,
-userChrome.css - doesn't work
-stylesheet service - doesn't work
-html:link - works

Test case coming up.

Comment 1

[Jason Barnabe (np)]

Attachment: testcase

The testcase defines a label with id, foo, and isDisabled attributes. A user style selecting label[id] or label[foo] will work, but a user style selecting label[isDisabled] will not.

Again, if you're using Stylish in Firefox 2.0 or earlier to apply these styles, it *will* work until the page is reloaded.

Comment 2

[Jason Barnabe (np)]

HTML documents don't seem affected by this bug.

Comment 3

[Jason Barnabe (np)]

It's not just isDisabled, it's anything that starts with "is" followed by a capital letter.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is the XUL code doing incorrect case normalization on attribute names?  Does [isdisabled] match it?

Comment 5

[:Gavin Sharp [email: [e-mail]]]

This reminds me of bug 282328.

Comment 6

[Ian Moody [:Kwan] (UTC+1)]

(In reply to comment #4)
> Is the XUL code doing incorrect case normalization on attribute names?  Does
> [isdisabled] match it?
> 
Not that I can see.

Comment 7

[Jason Barnabe (np)]

Upon further testing, this bug affects any attribute name with a capital
letter.

DOMI shows the attribute's name correctly and getAttribute returns the correct
values.