This is a regression from Firefox 2. Works: 2007120218 Fails: 2007120218 Regression range is: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-12-02+17%3A00&maxdate=2007-12-02+19%3A00 Seems to be caused by Bug 390565. I don't succeed in adding keywords for this bug.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
A reduced testcase here would be great.
It's the following markup that messes us up: <table> <form action="/cgi-bin/legp504.exe"> <input type="hidden" name="ses" value="081"> <input type="hidden" name="typ" value="bil"> <input type="text" name="val"> <input type="submit" value="go"> ... The first two hidden <input>s stay where they are, but the last non-hidden in gets moved out, and so the inputs are reordered and the site barfs.
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
QA Contact: general → parser
A way to do that would be to call tell the form in a special way the first time we are inserted into a form after having SetForm forcefully set on an element.
So... currently HTML5 says to submit in DOM order (or rather in .elements order, which is DOM order). We used to submit in .elements order, but it wasn't DOM order. Making it DOM order not only simplified the setup, but let us implement some things like :default without major performance penalties. As I see it, the options are: 1) Stop storing .elements in DOM order 2) Stop submitting in .elements order 3) Declare that we're done bending over backwards here and get this site to fix their code. Note that at this point to be bitten, a site must do all of the following: * Have a hidden input in an invalid spot inside a table (common enough, but rare in the global sense) * Have a non-hidden input in an invalid spot (pretty rare, since they get visibly hoisted out of the table) * Be doing hand-parsing of the POST data instead of using some sort of off-the-shelf library, so they depend on the order (again surprisingly common, but not that common in a global sense). This site seems to have hit all three points, but it's the only one reported in the last 9 months to hit them... My gut instinct is option 3 above, honestly.
Well, the only thing is that if we did what comment 4 talks about we could back out the parser changes that only moves <input>s sometimes, which IMHO is a bit ugly.
That would mean that we'd not submit in .elements order in some other cases. For example: <tr> <td><input></td> <input type="hidden"> <td><input><td> </tr> DOM/.elements order will be "hidden, text, text" if we move the hidden input out. Submit order will be .... what?
Boris's comment: ".. Declare that we're done bending over backwards here and get this site to fix their code."? ... not sure who asked you to bend over, but I'll be happy to "fix" it. Please note this app was written in 1996... maybe when some of you young whipper-snappers were still in high-school. By the way, your "bug page" seems to have a js "bug" (textboxFocusEvent is null).. (sInputValue.length === 0)
Well, we've spent several years now trying to emulate IE's behavior here while still having a tree structure for the DOM. There's a pretty long history of issues with this particular kind of setup. If you're willing to change the server to not depend on the exact ordering, or to move the controls to right before the table, that would be much appreciated!
I may have found another site with the same problem. My high school proudly informed me that they just brought up a new website and invited me to check it out. I did, and noted some out-of-date contact information. When I tried to update my profile (in Firefox 3, of course) the "edit" or "save buttons didn't work. I was able to update things in IE. I checked the source code of the profile page and saw lots of inputs with hidden values, so I suspect it is the same issue. The site is www.holderness.org, but you need my ID & password to get to the profile page with the issue. I will supply it to Mozilla bug zappers in other than this public forum. Please email me.
John, please feel free to mail any information needed to reproduce (including the steps to do so) to my @mit.edu address.
John, thanks for sending the information! That site doesn't look related to this bug: they're not nesting inputs inside of <table> or <tr> directly.
Not going to block on this, but we really want this fixed asap.
Priority: -- → P1
So I do actually think we should try to fix this. Mostly because I think that if we do this by retaining insertion-order until someone mucks with the DOM we'll actually have a simpler solution. Right now we're doing these special hacks in the parser in order to not move type=hidden. We wouldn't need to do this if we could tell parser-insertions from other DOM mucking.
Actually, I suspect we still would because people clone table rows with hidden inputs in them, iirc... Not sure whether that's more or less common than some of the other weirdness.
Looks like Ria provided the regression range and it looks like Jonas found the offending makeup. Do we still need qawanted?
It seems to me that the site has fixed itself. The issue from comment 3 is WONTFIX per HTML5. Please file a bug against the HTML5 spec if you disagree.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.