Closed Bug 277724 Opened 17 years ago Closed 15 years ago

[FIX]<select> and <textarea> don't restore disabled state

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
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.
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.
> Both textareas and selects have plenty of unused bits.

They do?  Am I just being blind?  LXR link, please?
*** Bug 300364 has been marked as a duplicate of this bug. ***
Just some remarks:
IE6 doesn't restore the disabled state.
With bfcache on (which is on by default), this is 'automatically' fixed.
Attached patch Fix (obsolete) — Splinter Review
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)
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 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+
Attachment #245370 - Attachment is obsolete: true
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Duplicate of this bug: 375972
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.
Depends on: 818011
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.