Closed Bug 452604 Opened 16 years ago Closed 14 years ago

Javascript search query could not be interpreted

Categories

(Core :: DOM: HTML Parser, defect, P1)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: john_josephs, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Using the search box on the reported web page always returns an error after upgrading to Firefox 3.  It worked in version 2, and still works in IE.


Reproducible: Always

Steps to Reproduce:
1.Type hb1 into the search box
2.hit Enter or click on the "Go" button
3.
Actual Results:  
Brings up an error page:
 Sorry, your query could not be properly interpreted.

Expected Results:  
Should take me to the following page (result produced in IE)
http://leg1.state.va.us/cgi-bin/legp504.exe?ses=081&typ=bil&val=hb1

I think it is a javascript function that is failing, but I know very little about programming.  Curiously, a similar search box still works on another page on the site:
http://leg1.state.va.us/cgi-bin/legp504.exe?081+men+SRB
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.
Blocks: 390565
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Flags: blocking1.9.1?
A reduced testcase here would be great.
Keywords: qawanted
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
I wondered aloud to sicking if we should remember source index in form elements and then invalidate (and only use the DOM) if the structure of the form changes due to JavaScript.
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.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
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?
Keywords: 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
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.