Closed Bug 589975 Opened 14 years ago Closed 14 years ago

NS_GetRadioUpdateValueMissingVisitor shouldn't have a aNotify parameter

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- final+

People

(Reporter: mounir, Assigned: mounir)

References

Details

Attachments

(1 file)

Given that the aNotify parameter is used for all radios in the radio group, it will not apply except for the caller.
Blocks: 589977
Assignee: nobody → mounir.lamouri
blocking2.0: --- → final+
Attached patch Patch v1Splinter Review
Attachment #479605 - Flags: review?(jonas)
Status: NEW → ASSIGNED
I don't understand, why is this safe? If removeElement is called with aNotify=false, then it's quite possibly because it's not safe to do notifications.
Comment on attachment 479605 [details] [diff] [review]
Patch v1

Removing review request while waiting
Attachment #479605 - Flags: review?(jonas)
(In reply to comment #2)
> I don't understand, why is this safe? If removeElement is called with
> aNotify=false, then it's quite possibly because it's not safe to do
> notifications.

I guess this comment applies for bug 589977 instead?

IIRC, the reason of this bug is aNotify passed to the visitor doesn't really apply on all radio elements. That's what have been done for nsHTMLFormElement::UpdateValidity. Boris told me that assuming PR_TRUE was the best solution.
Comment on attachment 479605 [details] [diff] [review]
Patch v1

Re-requesting per comment 4.
Attachment #479605 - Flags: review?(jonas)
Whiteboard: [needs review]
Whiteboard: [needs review]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/0d88025a123f
Target Milestone: --- → mozilla2.0b8
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: