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

Status: RESOLVED FIXED

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

Description

[Boris Zbarsky [:bzbarsky]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So the real question is, do we want to be restoring disabled state, in general?
 We do for <input>....

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

IMHO we do want to restore it. The more we restore the better.

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK.  Thoughts on how to do this reasonably?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Both textareas and selects have plenty of unused bits.

They do?  Am I just being blind?  LXR link, please?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Martijn Wargers (dead)]

*** Bug 300364 has been marked as a duplicate of this bug. ***

Comment 8

[Martijn Wargers (dead)]

Just some remarks:
IE6 doesn't restore the disabled state.
With bfcache on (which is on by default), this is 'automatically' fixed.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

I found that <button> doesn't restore disabled state either while doing this...

Comment 10

[Johnny Stenback (:jst)]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated to comments, merged to tip

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 14

[ainfo]

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.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is not the right forum for that discussion. Please raise it in the newsgroups.