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 ;)
Created attachment 215716 [details] 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
Not seeing "passed" in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060319 Firefox/188.8.131.52 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
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?
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? → blocking1.9-
I see the expected behavior and I see the same thing on Chrome 30. IE11 on the other hand... no 'passed' is displayed!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
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.