Closed
Bug 277724
Opened 20 years ago
Closed 18 years ago
[FIX]<select> and <textarea> don't restore disabled state
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
Details
Attachments
(1 file, 1 obsolete file)
24.99 KB,
patch
|
Details | Diff | Splinter Review |
Part of the problem is that they don't have a flag to indicate that this state has changed, unlike <input>. So they'd have to save it unconditionally or add some members. There's also the question of what to do about the disabled state of options. We should probably save and restore that too, but going through all options like that could be expensive.
Assignee | ||
Comment 1•20 years ago
|
||
So the real question is, do we want to be restoring disabled state, in general? We do for <input>....
IMHO we do want to restore it. The more we restore the better.
Assignee | ||
Comment 3•20 years ago
|
||
OK. Thoughts on how to do this reasonably?
Just like <input> should be fine. Both textareas and selects have plenty of unused bits. We could use even bitfield syntax to compress the data since it won't matter very much if compilers can't compress the data optimally.
Assignee | ||
Comment 5•20 years ago
|
||
> Both textareas and selects have plenty of unused bits.
They do? Am I just being blind? LXR link, please?
31 free bits here: http://lxr.mozilla.org/mozilla/source/content/html/content/src/nsHTMLSelectElement.cpp#401 3*7 bits here: http://lxr.mozilla.org/mozilla/source/content/html/content/src/nsHTMLTextAreaElement.cpp#143
Comment 7•19 years ago
|
||
*** Bug 300364 has been marked as a duplicate of this bug. ***
Comment 8•19 years ago
|
||
Just some remarks: IE6 doesn't restore the disabled state. With bfcache on (which is on by default), this is 'automatically' fixed.
Assignee | ||
Comment 9•18 years ago
|
||
I found that <button> doesn't restore disabled state either while doing this...
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #245370 -
Flags: superreview?(jst)
Attachment #245370 -
Flags: review?(jst)
Assignee | ||
Updated•18 years ago
|
Flags: in-testsuite?
Priority: -- → P3
Summary: <select> and <textarea> don't restore disabled state → [FIX]<select> and <textarea> don't restore disabled state
Target Milestone: --- → mozilla1.9alpha
Comment 10•18 years ago
|
||
Comment on attachment 245370 [details] [diff] [review] Fix - In nsHTMLTextAreaElement::BeforeSetAttr(): + if (aNotify && aNameSpaceID == kNameSpaceID_None && + aName == nsHTMLAtoms::disabled) { + mDisabledChanged = PR_TRUE; + } Given that 99+% of the attributes ever set on HTML elements have no namespace, I'd reorder the if condition to check the name before checking the namespace id. Same applies to all BeforeSetAttr() methods in this patch. r+sr=jst with that.
Attachment #245370 -
Flags: superreview?(jst)
Attachment #245370 -
Flags: superreview+
Attachment #245370 -
Flags: review?(jst)
Attachment #245370 -
Flags: review+
Assignee | ||
Comment 11•18 years ago
|
||
Attachment #245370 -
Attachment is obsolete: true
Assignee | ||
Comment 12•18 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Comment 14•17 years ago
|
||
I think that there might be some larger issues at play here that need further discussion. I thought http was stateless so if you disable a control and reload the page the control would not store state from the previous page load -- in particular the disabled control would be reenabled on page reload. It would be nice if a summary explination of why Firefox maintains state (in particualr the disabled state) across page reloads.
This is not the right forum for that discussion. Please raise it in the newsgroups.
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•