184732 - setAttribute("value") affects .value differently at different times

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect, P5)

Description

[John Keiser (jkeiser)]

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.

Comment 1

[John Keiser (jkeiser)]

Attachment: Value Tester

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

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 3

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

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).

Comment 4

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

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

:)

Comment 5

[Daniel Wang]

what's the relation between this bug and bug 108482 ? dupe? dependent?

Comment 6

[Boris Zbarsky [:bzbarsky]]

None, really.  XUL should not be using setAttribute("value") no matter what
happens to this bug, or even if nothing happens.

Comment 7

[Daniel O'Connor]

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

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Marking invalid.  The current behavior is in the HTML spec and is interoperable across all browsers at this point, I believe.