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)
Toolkit
Add-ons Manager
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
Comment 1•15 years ago
|
||
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
Comment 2•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
(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: ? → -
Comment 4•15 years ago
|
||
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.
| Reporter | ||
Comment 5•15 years ago
|
||
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.
Comment 6•15 years ago
|
||
(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.
Comment 7•15 years ago
|
||
(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.
Description
•