409494 - Inconsistent display of <input type="image"> when "type" attribute is set dynamically

Status: NEW

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

Description

[Jesse Ruderman]

The testcase and reference *should* have the same final DOM, but somehow, in the testcase, the <input> gets an extra value attribute (value="").  This prevents the default text "Submit Query" from appearing.

(This is in a build that has the fix for bug 408782.)

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[Jesse Ruderman]

Attachment: reference

Comment 3

[Boris Zbarsky [:bzbarsky]]

The issue is that we're saving the text control's value in the attribute.  See nsHTMLInputElement::TakeTextFrameValue (called when we tear down the text control when we're removing the node from the document) and the SetAttr call in nsHTMLInputElement::AfterSetAttr that saves mValue in the attribute.

It's not quite clear what the right behavior is here exactly.  But it's all DOM code.

Comment 4

[Jesse Ruderman]

Attachment: testcase 2

Same issue with type="submit" instead of type="image".

Comment 5

[Jesse Ruderman]

Attachment: reference 2

Comment 6

[Jesse Ruderman]

Attachment: reference 2

Comment 7

[WADA:World Anti-bad-Duping Agency]

Attachment: Test case to see i.value/i.getAttribute('value'), and affect by history

(Test-1)  (similar to onLoad="r();" by already attached test cases)
  1. Load the HTML
  2. "Move to body"
  3. "Check Value"
  4. "Set as submit" => problem of this bug is observed
(Test-2)
  5. "Set as text"
  6. "Change Attribute Value string", "Change i.value string"
  7. "Check Value"
  8. Type text in input area (say 'XXXX')
 10. "Check Value"
 11. "Set as submit" => 'Attrib-String' is used (not string of i.value) 
 12. "Set as button" => 'XXXX' is used for value-attribute&i.value
 13. "Set as text"   => 'XXXX' is used for value-attribute&i.value

(12) looks to be a result of "Form History".
And, difference between (11) and (12) seems to be a result of inconsistency in setting of text string among input element types.
  from i.value, or from value-attribute

Comment 8

[WADA:World Anti-bad-Duping Agency]

Note:
When step(3), i.getAttribute('value') returned "null"(Null object).
But when step(4), i.getAttribute('value') returned null string(string of length 0).

Comment 9

[WADA:World Anti-bad-Duping Agency]

(A) When "input type=text", different value of DOM-1's i.attribute('value') and value of DOM-0's i.value(data in the input box) should be held.
In contrast to it, other types(such as button) has no need of different values. So, current implementation on other than "type=text" looks to keep same value.
  On change by i.setAttribute('value'), i.value is also changed.
  On change by i.value, value of i.getAttribute('value') is also changed.
(B) And, when change to 'type=text', attribute-value & i.value looks to be set from i.value. But, when other than 'type=text", attribute-value & i.value looks to be set from attribute-value.
(C) Further, "Form History" looks to change i.value to third value at somewhere.

I think above is main reason why funny behaviour in my test.

As I wrote in comment #8, i.getAttribute('value') returns Null Object instead of null string(string of length=0) initially.
So, if the initial "Null Object" status(no VALUE attribute in <INPUT> tag) is consistent, and if the initial "Null Object" status can be detected/handled on type change, I think re-setting to default text("Submit Query" when submit) can be implemented, without breaking current implementation explained in Comment #3 by Boriss.
   When attribute-value="Null Object", change value(i.value) only,
   and don't change attribute-value to null string(string of length=0).

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> but somehow, in the testcase, the <input> gets an extra value attribute (value="").

As I wrote in comment #8, the extra attribute(value="") appears after i.setAttribute('type','submit'), instead of after document.body.appendChild('i').
  (1) document.body.appendChild('i')  => null == i.getAttribute('value')
  (2) i.setAttribute('type','submit') => ""   == i.getAttribute('value')
      And submit button's text becomes "".
But when (B) is executed without (A), button's text becomes "Submit Query", and null == i.getAttribute('value') is kept.

Following phenomenon was observed without parent change of <input> of your case.
  (0) <input type="text"> in HTML
  (1) i.setAttribute('type','submit') => button becomes "Submit Query"
                                         null == i.getAttribute('value') 
  (2) i.setAttribute('type','button') => button with "" displayed
                                         "" == i.getAttribute('value')
  (3) i.setAttribute('type','submit') => submit button becomes ""
                                         "" == i.getAttribute('value')
Both of parent change by document.body.appendChild(i) and type change by i.setAttribute('type','submit') look to involve "removing the node from the document" in Comment #3.

(In reply to comment #3)
> SetAttr call in nsHTMLInputElement::AfterSetAttr that saves mValue in the attribute.

I think that null of "value" attribute(Null Object) is better to be kept always, if "value" attribute is set as null(Null Object).
Is there any way to know whether currently used text string(such as mValue in your Comment #3) is set by user's request or by internal mechanism described in Comment #3?

Comment 11

[WADA:World Anti-bad-Duping Agency]

When text is typed in initial <input type=text>, phenomenon becomes clear.

(Case-1) No parent change. setAttribute('type',..) twice
(1-1) Shift+Reload of test case of Comment #7
(1-2) Type XXX in input => value-attr=null, i.value=XXX (mValue=XXX, probably)
(1-3) "Set as button"   => value-attr=null, i.value=""  (mValue=XXX, probably)
(1-4) "Set as submit"   => value-attr=XXX,  i.value=XXX (set from mValue)
Value attribute was changed to XXX, by two i.setAttribute('type',...).

(Case-2) With parent change
(2-1) Shift+Reload of test case of Comment #7
(2-2) Type YYY in input => value-attr=null, i.value=YYY (mValue=YYY, probably)
(2-3) "Move to body"    => value-attr=null, i.value=YYY (mValue=YYY, probably)
(2-4) "Set as submit"   => value-attr=YYY,  i.value=YYY (set from mValue)
Value attribute was changed to YYY, by a document.body.appendChild(i) and an i.setAttribute('type',...).
Original problem looks to be i.value=""(mValue="") case of (Case-2).

Funny phenomenon in my previous test is explained by comment #3 and above results.

(Case-3) No parent change. change from type=text to other, and back to type=text
(3-1) Shift+Reload of test case of Comment #7
(3-2) Type ZZZ in input => value-attr=null, i.value=ZZZ (mValue=ZZZ, probably)
(3-3) "Set as button"   => value-attr=null, i.value=""  (mValue=ZZZ, probably)
(3-4) "Set as text"     => value-attr=null, i.value=ZZZ (set from mValue)
i.value was changed to ZZZ, but value attribute was kept as null, when change back to type=text. 

Why value attribute was set to mValue when (1-4) but kept as null when (3-4)?
Following is a part of "i.value=XXX request changes value arribute to XXX" when input element other than type=text?
> the SetAttr call in nsHTMLInputElement::AfterSetAttr that saves mValue in the attribute.

Comment 12

[WADA:World Anti-bad-Duping Agency]

Question about my test result.
> (Case-1) No parent change. setAttribute('type',..) twice
> (1-1) Shift+Reload of test case of Comment #7
> (1-2) Type XXX in input => value-attr=null, i.value=XXX (mValue=XXX, probably)
> (1-3) "Set as button"   => value-attr=null, i.value=""  (mValue=XXX, probably)
> (1-4) "Set as submit"   => value-attr=XXX,  i.value=XXX (set from mValue)

At step (1-3), value-attribute=null supersedes i.value=XXX at type=text era, and i.value is set to "", and it is consistent with value-attr=null(i.e. not specified in HTML).
What is reason why sets attrib-value(then i.value) from mValue at step (1-4), instead of from value-attr=null, when new type is other than type=text and value-attr=null?
("How XXX is set" is already explained by comment #3. I'm asking why.)

Comment 13

[Jesse Ruderman]

WFM?

Comment 14

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.