331156 - Dynamically changing file input to other input type doesn't show the default text inside the input

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase.
In all the input types I would expect the word 'passed' to appear, but that doesn't happen.
This is a regression, it doesn't happenin 2004-08-09 build, happens in 2004-08-10 build.
So I'm guessing it's a regression from bug 230170, but if it isn't please don't fix it, Boris ;)

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Bonsai link of regression range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-09+06%3A00%3A00&maxdate=2004-08-10+07%3A00%3A00&cvsroot=%2Fcvsroot

Comment 2

[Worcester12345]

Not seeing "passed" in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060319 Firefox/1.5.0.2 ID:2006031904

or:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060320 SeaMonkey/1.5a ID:2006032009

or:
ie Version: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Comment 3

[Boris Zbarsky [:bzbarsky]]

sicking, what do you think we should be doing here?

Comment 4

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

yeah, ideally we should pass this testcase as written i'd say.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I don't really see how this used to work, given the SetValueInternal call we make in nsHTMLInputElement::ParseAttribute....  This probably is a regression from bug 230170 somehow, presumably because we actually set the value in the content node now, not in the frame that's about to die.  Or the other way around.  Or something.  But the real issue is that we're setting the current value, which really ought to lead to the observed behavior.  Sounds like we should really do that splitting up of value storage for file inputs.  Sicking, is there a bug on that?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Note that even with the patch for bug 334977 this problem exists (since that patch still clears the "non-file" value.

sicking, perhaps we should just always set the "non-file" value when SetAttr or SetValue happens?

Comment 7

[Guilherme Lima]

I see the expected behavior and I see the same thing on Chrome 30.
IE11 on the other hand... no 'passed' is displayed!

Comment 8

[Guilherme Lima]

Sorry for the bugspam, just correct myself, I meant IE10.