Closed Bug 301226 Opened 19 years ago Closed 19 years ago

Cannot unset readonly on text-area element

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ole.ersoy, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Hi,

It would be great to able to unset the readonly attribute on a text-area element.

Currently, setting text-area's readonly attribute to anyting will make the
text-area readonly, and there is no way to unset it.

I've tried setting it to '', null, 'null', and even
var textAreaElementReadonlyDefault = textAreaElement.getAttribute('readonly');

In other words just setting the text-area readonly attribute, makes the
text-area readonly.

The html specification indicates that setting it to 'readonly' should make it
readonly.  One would think any other value would make it editable.

Reproducible: Always

Steps to Reproduce:
- Create a document with a text-area.
- Execute javascript setting the readonly attribute to anything
  by clicking in the area.

<html>
<head>
<script>
function setReadonly()
{
var text = document.getElementById('textarea');
text.setAttribute('readonly', '');
}
</script>
</head>
<body style="width:100%">
<text-area style="width:100%; height:100%"
           onMouseUp="setReadonly()"
/>
</body>
</html>

Now type some text and then click in the text-area...the text can no longer be
edited
Actual Results:  
The text-area is now readonly, although the readonly attribute was just set to ''.

Expected Results:  
Setting the readonly attribute to '', or any value other than 'readonly' should
make the field editable.
No, you have to completely remove the attribute:
text.removeAttribute('readonly');
Aha!  Thanks for the tip.

We should probably consider having one standard way of
setting attributes though.

I would think the rule should be that:

If an attribute is set to a w3c css specification
value, then it should behave in accordance with that
value.

If it is set to anything else, such as '', null, or
'Seinfeld', it should behave as if it has not been
set.

This is how the display css attribute works for
instance.

It would be much more intuitive for web developers if
everything behaved according to the same rule.

Thanks,
- Ole
See:
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68F082
null as argument should not work, it should raise an error.
'Seinfeld' or '' should work just fine.
Ah - OK - I took a look at the specification for setting attributes:

It says this: NO_MODIFICATION_ALLOWED_ERR: Raised if this node is readonly

This makes me think that when I tried to unset or reset the readonly attribute
on the textarea, I should have gotten an error message or warning in the
javascript console when the browser compiled the script...something like...

"Invalid value.  The readonly attribute, once set, can not be set to any other
value.  If you want the field to be editable, use use removeAttribute(attr),
where attr is the readonly attribute on the field you want to make editable.

Currently, when I run this:
                notesTextAreaElementClone.setAttribute('readonly','junk');
                alert(notesTextAreaElementClone.getAttribute('readonly'));
The the alert message contains 'junk', and there is nothing in the javascript
console telling me that this is not allowed for readonly that have been set.

No, you're seeing it wrong.
Any attribute node can be readonly, when it is defined that way.
The 'readonly' attribute node is called 'readonly', but is readable and writable
from a dom point of view.
OK,

So what does this mean then:
NO_MODIFICATION_ALLOWED_ERR: Raised if this node is readonly

In other words, when do we get an error?

The NO_MODIFICATION_ALLOWED_ERR in the specification is given in the context of
the setAttribute function.

The attribute belongs to the node.  So if the attribute is a readonly attribute,
and it is set, the the node becomes readonly right?

So if I programmatically try to change the context of the node, is that when I
get an exception?

The answer is no, because I tried it:
              notesTextAreaElementClone.value='junk';
              alert(notesTextAreaElementClone.value);
No exception and no errors or warning...and now we have covered the only two
cases where an exception could be thrown.

The field is still readonly...I could not change it in the browser, but the
value was changed and displayed in the browser programmatically and no exception
was thrown...

Anyways, I understand this now, but it would be great for others if this was
made more intuitive for web developers in general.

Currently some attributes, when set to '', behave as if they were never set,
like display, and it would be great if this type of consistency was applied
across the browser.

If the browser does not throw an exception when a readonly node's value is
changed and does not give warning or errors when a readonly attribute is
changed, then what is the point of the 

NO_MODIFICATION_ALLOWED_ERR ?

If we interpret the specification in the way I recommended then the browser
becomes easier to develop with.


A textarea.value is a dom propery and is actually something different than a
textarea value attribute. They are both read/writable.
I don't know of any html attributes that are readonly.
Here's the context:

The 'readonly' attribute only makes sense for nodes that are editable.  

Non-editable nodes are automatically readonly.  

So when we set readonly on an editable node, such as a textarea or text field,
our intention is to make sure that that node can no longer be edited.

What we are discussing is the interpretation of the w3c specification.

If we interpret the way I recommended above, it makes the life of everyone web
developer easier, because behavior of editable nodes now falls inline with the
way non-editable nodes in firefox behave.  Web developers expect consistency
across the browser.

Ideally we would go through and check that all the nodes conform to an agreed
upon rule set for how the node behaves per set values.  

THE RULE THAT WOULD MAKE MOST SENSE FOR EVERYONE:
I think the rule that makes most sense for everyone is that if a node attribute
is set to a valid css specification value, then the browser renders what the
value indicates, otherwise the browser just goes with the default value.

If it is set to an invalid value, the browser just ignores it and publishes a
warning or error in the javascript console.

This would be inline with the w3c specification and very helpful to developers.
This is not going to change, see bug 171840 and bug 181839.
Well,

I really appreciate your feedback either way.  It helped me get the javascript I
was writing to be as simple as possible.

Anyways I put forth my best arguements and I hope they help make firefox an even
greater browser.

Thanks again,
- Ole
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.