Closed Bug 599702 Opened 15 years ago Closed 15 years ago

In AOM, .global-warning-container should have status attributes

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -

People

(Reporter: pjdkrunkt, Unassigned)

References

Details

(Whiteboard: [mozmill])

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/20100101 Firefox/4.0b6 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/20100101 Firefox/4.0b6 In order to properly apply styles to the AOM, the .global-warning box should have some kind of attribute either for each warning, or to signify that there are no warnings. Reproducible: Always
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager
It's also something we will need for Mozmill to identify which warning is shown. I haven't found a way yesterday.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [mozmill]
Version: unspecified → Trunk
It's similar to the add-on entries in the list view. There is no DOM attribute or JS property available to determine if the given addon is incompatible. There is only a warning DOM attribute set, but it's not clear enough which different states it can expose.
(In reply to comment #1) > It's also something we will need for Mozmill to identify which warning is > shown. I haven't found a way yesterday. Testing the visibility of the warnings would help for this case. This will not block the release.
blocking2.0: ? → -
I still don't understand why this would be needed - for global warnings, just look for the warning attribute on the root <page> element. It doesn't make sense to me to put that attribute on individual views - since it has nothing to do with any specific view.
Aha! Thank you Blair, I guess I was looking too low in the structure and never thought to look at the highest level for that attribute. That should be enough for themers.
(In reply to comment #3) > (In reply to comment #1) > > It's also something we will need for Mozmill to identify which warning is > > shown. I haven't found a way yesterday. > > Testing the visibility of the warnings would help for this case. > This will not block the release. Well, I also want to know which warning is shown. Means if compatibility or secure update checks are disabled, or if we are in safe mode. How can we distinct between those different warnings? I can't find an attribute or property to use for.
(In reply to comment #6) > Well, I also want to know which warning is shown. Means if compatibility or > secure update checks are disabled, or if we are in safe mode. How can we > distinct between those different warnings? I can't find an attribute or > property to use for. That's also contained in the "warning" attribute on the page element. For instance, if compatibility checking is disabled, the warning attribute will be set to "checkcompatibility". See the refreshGlobalWarning function: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions.js#275
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.