Closed
Bug 297761
Opened 19 years ago
Closed 19 years ago
Form with blank action submitted to base.href
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: mozilla, Unassigned)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files, 2 obsolete files)
204 bytes,
text/html
|
Details | |
1.29 KB,
patch
|
chofmann
:
approval1.8b3+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+ a page (http://www.example.com/sub/test.php) contains <FORM action="" method="get" name=""> In previous version of firefox and in IE this is submitted back to http://www.example.com/sub/test.php in deer park alpha 1 it is submitted to http://www.example.com/sub/ Reproducible: Always
Comment 1•19 years ago
|
||
http://philringnalda.com/mtests/test.php WFM in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050615 Firefox/1.0+ If you have an actual example with something else more complicated going on, we'd need to see it to reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 2•19 years ago
|
||
OK, this example works - it appears that this actually results from a interaction of the blank action and BASE href. It might even be argued that it is the correct behaviour - but it is different from previous versions & IE. <html> <head> <BASE href="http://www.dilbert.com/"> </head> <body> <form action="" method="get"> <input type="submit"> </form> </body> </html>
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 3•19 years ago
|
||
Ah, yeah. That would be the result of fixing bug 280470, but I know at least I didn't think about the fact that people might be relying on the odd way that HTMLFormElement.action is specified as a string. Both Opera and IE do follow the letter of the spec and not resolve that to base.href bz, jst - are we sure we want to be reasonable instead of 'right' and following the herd here?
Assignee: nobody → general
Component: General → DOM: HTML
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → ian
Hardware: PC → All
Summary: Form with blank action is submited to the wrong page → Form with blank action submitted to base.href
Version: unspecified → Trunk
Comment 4•19 years ago
|
||
Trivial testcase
Comment 5•19 years ago
|
||
Replacing the 1304 // 1305 // Grab the URL string 1306 // 1307 nsAutoString action; 1308 GetAction(action); code in nsHTMLFormElement::DoSubmit with a GetAttr() call instead might help here...
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b3?
Keywords: regression
Comment 6•19 years ago
|
||
Attachment #187323 -
Flags: superreview?(jst)
Attachment #187323 -
Flags: review?(jst)
Comment 7•19 years ago
|
||
Shouldn't <form> behave the same way <form action=""> does? If so, the rv == NS_CONTENT_ATTR_HAS_VALUE check should go. No?
Comment 8•19 years ago
|
||
yes, <form> should be equivalent to <form action="">.
Comment 9•19 years ago
|
||
(In reply to comment #7) > Shouldn't <form> behave the same way <form action=""> does? Yes, but GetURIAttr() already does the right thing for this case so the bug is only for action="". But we can handle them both here if you prefer. > If so, the rv == NS_CONTENT_ATTR_HAS_VALUE check should go. No? That would turn *_ERROR into NS_OK.
Attachment #187461 -
Flags: superreview?(jst)
Attachment #187461 -
Flags: review?(jst)
Comment 10•19 years ago
|
||
Comment on attachment 187461 [details] [diff] [review] Patch rev. 2 - In nsHTMLFormElement::GetAction(): + if (aValue.IsEmpty()) { + // Avoid resolving action="" to the base uri, bug 297761. + return NS_OK; + } else { Remove the else-after-return. r+sr=jst with that change.
Attachment #187461 -
Flags: superreview?(jst)
Attachment #187461 -
Flags: superreview+
Attachment #187461 -
Flags: review?(jst)
Attachment #187461 -
Flags: review+
Updated•19 years ago
|
Attachment #187323 -
Attachment is obsolete: true
Attachment #187323 -
Flags: superreview?(jst)
Attachment #187323 -
Flags: review?(jst)
Comment 11•19 years ago
|
||
With last comment addressed.
Attachment #187461 -
Attachment is obsolete: true
Attachment #187523 -
Flags: approval1.8b3?
Comment 12•19 years ago
|
||
Comment on attachment 187523 [details] [diff] [review] Patch rev. 3 a=chofmann
Attachment #187523 -
Flags: approval1.8b3? → approval1.8b3+
Comment 13•19 years ago
|
||
Checked in to trunk at 2005-06-28 16:22 PDT -> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Flags: blocking1.8b3?
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•