User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021112 Build Identifier: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021112 The following is a live example HTML snippet ------------------------- <html> <body> <form method="get" action=""> <br><br> <p>Choose one (or not): <select name="account_type"> <option value="A" >A</option> <option value="B" >B</option> </select> <input type="submit" name="btn_submit" value=" > "> <input type="hidden" name="account_type_selection" value="1"> <input type="hidden" name="mw_session_id" value="b99e413123828cd1d027df48d83c3723"><input type="hidden" name="mw_step" value="create"> </form> <hr> <input type="hidden" name="mw_session_id" value="b99e413123828cd1d027df48d83c3723"><input type="hidden" name="mw_step" value="create"> </body> </html> --------------------------- (sorry for not posting a link, but the pages this is happening with are in a closed environment) If you read the above HTML, you'll find 2 params named "mw_session_id". One is inside the form, the other is outside However, both are passed along when submit is pressed. (you can see them both in the location bar) Reproducible: Always Steps to Reproduce: 1. Create the above file in your disk, point mozilla 1.2 or a galeon built against it to that file. 2. Click the form button 3. Read the URL in the location bar, and you'll find 2 mw_session_id and 2 mw_step Actual Results: Read the URL in the location bar, and you'll find 2 mw_session_id and 2 mw_step Even if the "outside" parameters have different names, they'll show up. This also works for POST. Many applications take this as an array, and will try to act accordingly. Unfortunately for session based interfaces, it kills the sessions. Expected Results: Only the mw_session_id and mw_step inside the form should be there. Not both. Oddly enough... if you remove the <p> tag or the <hr> tag, the form will work as expected. I have no clue whatsoever of why this is happening.
Created attachment 107822 [details] The above code in file form Download this file to test the symptoms
i'll say this is parser (content building). the DOM inspector shows me all inputs added to the only form in the document. whether is major or not, i'll let harish decide.
OK, parser is really screwing up this file (it seems to me)--the parent of that input should not be the FORM--but it *is* setting the input's form to null. The problem comes when SetParent() occurs; since the parent was null before SetParent, the element assumes that it is having its parent set through JS and sets the form. This is somewhat bad behavior anyway, and causes a slight performance problem in that elements that are *not* in a form are added via the content sink. Thus we need to know whether SetParent() was called in response to the content sink or not (since content sink wants to set the form itself). Alternatively, the content sink can fix the element's form to be null--set it to the proper form *after* calling AddLeaf.
Created attachment 108177 [details] [diff] [review] Patch v0.5 This patch fixes the issue by calling SetForm *after* the parent is set on the element. It turns out this is an issue for all form controls. The tricky part is making containers work. This will work in most cases, but since sometimes containers are not added to their parents until a flush, it is possible for the current form or the "inside xxx tag" boolean to have changed since element creation. The obvious solution there is to cache that information in the tag stack; I have not done that yet, and that is why this patch is 0.5. It is also possible, as noted before, to forego this solution and make the elements more complicated: tell the elements explicitly that they should not set the forms themselves (or remember that someone has already called SetForm on them). It seems to me that since HTMLContentSink is the one who is not being well-formed, HTMLContentSink should pay the price and leave other content sinks alone. Harish, what's your opinion? The parser problem needs to be fixed as well but this is a real problem with setting the form.
>OK, parser is really screwing up this file (it seems to me)--the parent of that >input should not be the FORM With the current model the parser does not make any decision about whether the form elements belong to the FORM in question or not rather it leaves the decision to the content sink. Also, the parser does not treat FORM as container ( may be it should though ) and hence does not force open containers such as P, inside the FORM, to autoclose. I'm sure that if the FORM was treated as a container, in the parser, this issue can be resloved, however, we should brace up for tons of regressions ( I believe ).
I can produce this problem on WinXP Build Id# 2005-04-02-405.. Hardware --> All OS --> All
*** Bug 253616 has been marked as a duplicate of this bug. ***
*** Bug 333997 has been marked as a duplicate of this bug. ***