Closed
Bug 572896
Opened 15 years ago
Closed 15 years ago
Split nsHTMLInputElement::Reset() to prevent calling it to set the default value to the current value
Categories
(Core :: DOM: Core & HTML, enhancement)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla2.0b3
People
(Reporter: mounir, Assigned: mounir)
References
Details
Attachments
(2 files, 2 obsolete files)
4.22 KB,
patch
|
Details | Diff | Splinter Review | |
8.05 KB,
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
It's a follow-up from bug 549475: it makes thing clearer when reading the code.
Attachment #452121 -
Flags: review?(Olli.Pettay)
Assignee | ||
Updated•15 years ago
|
Comment 1•15 years ago
|
||
Comment on attachment 452121 [details] [diff] [review]
Patch v1
How does this make the code easier to read. Yet another switch-case.
Assignee | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> (From update of attachment 452121 [details] [diff] [review])
> How does this make the code easier to read. Yet another switch-case.
Well, it prevents calling Reset when we don't really want to reset but set the value to the default value. In addition, the current call to reset is working only because we are calling it when the VALUE_CHANGED bit is false. For any reason, if that's done when VALUE_CHANGE is true, it would be wrong.
I admit a switch case isn't really readable but I think that worths it because when doing a first read of AfterAttrSet, you understand what's SetValueAsDefaultValue is doing and you don't have to ask yourself why Reset is called. In addition, with the ValueMode() function I've added in on of my patch, the size of the switch could be reduced to 4 lines (two cases). I could introduce this function (ValueMode()) in a separate patch if you think the patch in it's current shape is only making thing worse.
Updated•15 years ago
|
Attachment #452121 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 3•15 years ago
|
||
Refreshed patch.
Attachment #452121 -
Attachment is obsolete: true
Assignee | ||
Updated•15 years ago
|
Attachment #458636 -
Flags: approval2.0?
Assignee | ||
Comment 4•15 years ago
|
||
This is bug 549475 follow-up. Only refactorization. (for the approval)
Updated•15 years ago
|
Attachment #458636 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 5•15 years ago
|
||
Updated patch for checkin.
r=smaug a=bsmedberg
Attachment #458636 -
Attachment is obsolete: true
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 6•15 years ago
|
||
If you push this patch, could you push the patch from bug 572897 with it? (this patch has to be applied before)
Comment 7•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b3
Assignee | ||
Comment 8•15 years ago
|
||
Comment 9•15 years ago
|
||
volkmar: when @value is set, it becomes the <input> value if !BF_VALUE_CHANGED
volkmar: it was done with Reset() which was doing SetValue() then resetting BF_VALUE_CHANGED
ehsan: hmm, ok, makes sense I guess
volkmar: so i've introduced a new argument to not set BF_VALUE_CHANGED when doing SetValue
volkmar: SetValueInternal
volkmar: but i forgot to do that for SetChecked
Assignee | ||
Comment 10•15 years ago
|
||
To be more accurate, the new "SetValueAsDefaultValue" method do not reset BF_VALUE_CHANGED because SetValueInternal has a new argument to not set it. Reset() do reset it because it has to.
However, I forgot to take into consideration DoSetChecked.
Sorry about that :(
Updated•15 years ago
|
Attachment #459499 -
Flags: review+
Comment 11•15 years ago
|
||
Bustage fix pushed: http://hg.mozilla.org/mozilla-central/rev/0dc03dd97a06
You need to log in
before you can comment on or make changes to this bug.
Description
•