Closed Bug 182824 Opened 22 years ago Closed 14 years ago

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

Categories

(Core :: DOM: HTML Parser, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: ricardo-mozilla, Unassigned)

References

Details

(Whiteboard: [fixed by the HTML5 parser])

Attachments

(3 files)

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.
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
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.5Splinter 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: 14 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

Created:
Updated:
Size: