Closed Bug 182824 Opened 22 years ago Closed 15 years ago

<input> fields outside <form> are passed along... sometimes

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ricardo-mozilla, Unassigned)

References

Details

(Whiteboard: [fixed by the HTML5 parser])

Attachments

(3 files)

The above code in file form
(deleted), text/html
Details
Minimized Testcase
(deleted), text/html
Details
Patch v0.5
(deleted), patch
Details | Diff | Splinter Review
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.
Attached file The above code in file form (deleted) —
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.
Assignee: alexsavulov → harishd
Status: UNCONFIRMED → NEW
Component: Form Submission → Parser
Ever confirmed: true
QA Contact: vladimire → moied
Attached file Minimized Testcase (deleted) —
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.
Attachment #108155 - Attachment is patch: false
Attachment #108155 - Attachment mime type: text/plain → text/html
Attached patch Patch v0.5 (deleted) — — Splinter Review
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 ).
The parser issue here (in fact the whole issue here, I think) is bug 22480
Depends on: 22480
I can produce this problem on WinXP Build Id# 2005-04-02-405.. Hardware --> All OS --> All
OS: Linux → All
Hardware: PC → All
Whiteboard: testcase
*** Bug 253616 has been marked as a duplicate of this bug. ***
*** Bug 333997 has been marked as a duplicate of this bug. ***
Assignee: harishd → nobody
QA Contact: moied → parser
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: testcase → [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: