bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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




Layout: Form Controls
12 years ago
5 years ago


(Reporter: Martijn Wargers (zombie), Unassigned)


({helpwanted, regression, testcase})

Windows XP
helpwanted, regression, testcase
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)



(1 attachment)



12 years ago
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 2

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

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

ie Version: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
sicking, what do you think we should be doing here?
yeah, ideally we should pass this testcase as written i'd say.
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?
Blocks: 230170
Keywords: helpwanted
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?
Depends on: 334977
Flags: blocking1.9a2?
Flags: blocking1.9a2? → blocking1.9-

Comment 7

5 years ago
I see the expected behavior and I see the same thing on Chrome 30.
IE11 on the other hand... no 'passed' is displayed!
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Comment 8

5 years ago
Sorry for the bugspam, just correct myself, I meant IE10.
You need to log in before you can comment on or make changes to this bug.