Update callers for hasAttribute work



17 years ago
8 years ago


(Reporter: jag (Peter Annema), Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: bugday0420, URL)


(1 attachment)

4.10 KB, patch
Joe Hewitt (gone)
: superreview+
Details | Diff | Splinter Review


17 years ago
There are a bunch of places that still e.g. .setAttribute("checked", "false"),
.setAttribute("checked", someCondition), or .getAttribute("checked") == "false".
This use clashes with the use of .hasAttribute("checked") for the checked
property on checkbox.

Please fix these sites, or revert the logic in checkbox.xml until you have a
chance to fix them.

Comment 1

17 years ago
This may (in part) be causing bug 113482 and bug 113335.

I also suspect this bug is the reason why, when you go to preferences, when you
have all the checkboxes on the navigator panel unchecked, select another panel,
then select the navigator panel again, the checkboxes will now all be checked.

Comment 2

17 years ago
*** Bug 114250 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
I only found a few places that should be affected by the changes I've made so 
far, and only one was related to checkbox...
Summary: The world isn't ready for checkbox's hasAttribute("checked") instead of getAttribute("checked") == "true" → Update callers for hasAttribute work

Comment 5

17 years ago
Comment on attachment 61031 [details] [diff] [review]

Attachment #61031 - Flags: superreview+
Please make sure that


are a totally separate issue... (they look like they should be)

Comment 7

17 years ago
And then there's the other two possibilities I pointed out in my original 

E.g. |setAttribute("checked", a!=b)| and |var foo = el.getAttribute("checked"); 
if (foo != "false") { ... } else { ... }| (there's some of this somewhere in 
wallet code, twice, iirc).

Comment 8

17 years ago
I went through get/setAttribute calls and didn't find any more that would break 
as a result of my changes.  The one in wallet that I think you're referring to 
is commented out, but it doesn't refer to a checkbox anyways, it's a command.  


17 years ago
Target Milestone: --- → mozilla1.0.1

Comment 9

15 years ago
Target Milestone: mozilla1.0.1 → Future
Neil, do you have the time to wrap this up?
Target Milestone: Future → mozilla1.0.1
Product: Browser → Seamonkey
Assignee: bross2 → general
QA Contact: doronr → general

Comment 11

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

8 years ago
Marking this INCOMPLETE, as it's not sure this work has been completed, but then, if problems have not been fixed, they have been lurking for quite some time and very possibly have been rewritten and replaced since then anyhow.
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: bugday0420
You need to log in before you can comment on or make changes to this bug.