Closed
Bug 184732
Opened 22 years ago
Closed 6 years ago
setAttribute("value") affects .value differently at different times
Categories
(Core :: Layout: Form Controls, defect, P5)
Tracking
()
RESOLVED
INVALID
mozilla1.3beta
People
(Reporter: john, Assigned: john)
References
(Blocks 1 open bug)
Details
(Whiteboard: [whitebox])
Attachments
(1 file)
1.43 KB,
text/html
|
Details |
Currently, .setAttribute("value") affects .value up until the first time you set .value or change the control. This is a counterintuitive rule. It stems, however, from a difference between IE and the spec, and Mozilla's internal use of .setAttribute("value") in an IE-like way. IE's way: 1. value attr and .value are *always* the same 2. .defaultValue is completely independent of .value 3. If the value attr is parsed in from the HTML page, .defaultValue is set from it Our way: 1. value attr and .defaultValue are *always* the same 2. .value is completely independent of .defaultValue 3. .value is set whenever you set .defaultValue, *until* the value is changed, either through .value or typing in the input box. Our first two rules fit the spec better than IE's rules. (But perhaps the spec is wrong?) We have two approaches we can take here (other suggestions welcomed): 1. Initialize .value from .defaultValue the first time it is *read* instead of when it is changed. This will entail changing Mozilla code (which is fine) to use .value and will have an unknown number of regressions. 2. Go with IE, and file a bug on the spec. My only problem with this is that it makes .setAttribute("value") work differently depending on whether the parser set the attribute or not. Perhaps some modification of IE's rules could make it more consistent, but I haven't figured out what modification yet. I do *not* think we should leave the situation the way it is. Both of the above alternatives are lesser evils. It bloats the code and violates the Principle of Least Surprise.
Assignee | ||
Comment 1•22 years ago
|
||
This tests the behavior of the different sets and gets, and even tests what happens when you setAttribute("value") before inserting into the doc (in IE it is consistent; it doesn't set .defaultValue).
Comment 2•22 years ago
|
||
> in IE it is consistent; it doesn't set .defaultValue
This is the #1 reason not to do the IE way, imo. It should not matter whether I
document.write() my node or whether I synthesize it via DOM calls to
createElement and setAttribute; the results should be the same.
I'm all for fixing our internal callers to not be broken and then removing the
"value was modified" stuff.
I _think_ i prefer keeping it the way it is now. How do you define "the first time it is read"? Does layout reading the value to create the textbox count? Or would only JS reading .value "lock" it down? Do we have any code in mozilla that reads the .value of controls in the form? Does the page-info window or the accessibility-code? If layout reading .value would lock it it would be even worse. For example the following code myInput = document.createElement("input"); parent.appendChild(myInput); myInput.setAttribute("value", "hi"); will work most of the time. However if we happen to do a reflow between the .appendChild and the .setAttribute. Another example is if you have an input in the markup of a page and then call .setAttribute on it. If that part of the page is display:none then it will work, but not if it has ever been shown. This could get even worse with non-blocking loading of stylesheets since the networks speed could affect wether a display:none rule in a stylesheet would get applied before the input is first shown or not. The way i would ideally have it work is something like this: 1. .value and the value-attribute are always the same 2. .value is completely independent of .defaultValue 3. .defaultValue is set the first time setAttribute("value") is called (including when it is called by the parser).
Summary: setAttribute("value") affects ,value differently at different times → setAttribute("value") affects .value differently at different times
oh, and we don't *have* to make xul-textboxes behave like html-inputs. Does xul even have resetting? If not it would be a good simple model to have 1. .value is always the same as the value-attribute :)
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.3beta
Updated•22 years ago
|
Whiteboard: [whitebox]
Assignee | ||
Updated•22 years ago
|
Comment 5•21 years ago
|
||
what's the relation between this bug and bug 108482 ? dupe? dependent?
Comment 6•21 years ago
|
||
None, really. XUL should not be using setAttribute("value") no matter what happens to this bug, or even if nothing happens.
Comment 7•19 years ago
|
||
What's happening with this bug? As a developer, I'd love to be able to write helper functions like the below: function alterNodeList(nodes, attrib, value) { try { if (!instanceOf(nodes, NodeList)) { return false; } for (var i = 0; i < nodes.length ; i++) { nodes.item(i).setAttribute(attrib, value); } } catch (e) { alert(e); return false; } return true; } The use of a function like this would speed up and simplify *much* of what I'm doing - the same code to set the state for radio buttons, checkboxes, etc. Because this bug exists, I'm blocked from doing really basic things and it makes developing in javascript tedious. I'd really like clarity, and for a bug to be filed on the spec. Expected: tgt.setAttribute("foo","foo") is the same as tgt.foo = "foo". End of story.
Comment 8•19 years ago
|
||
> Expected: tgt.setAttribute("foo","foo") is the same as tgt.foo = "foo".
That's not the case for several properties, and |value| is one of those, more or
less because the "value" attribute doesn't reflect the "current value" and never
has in browsers. Sorry, but that's just the way it is; that has nothing to do
with this bug.
Updated•15 years ago
|
QA Contact: tpreston → layout.form-controls
Comment 9•6 years ago
|
||
Decreasing the priority as no update for the last 2 years on this bug. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage about the priority meaning.
Priority: P1 → P5
Comment 10•6 years ago
|
||
Marking invalid. The current behavior is in the HTML spec and is interoperable across all browsers at this point, I believe.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•