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)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files, 2 obsolete files)

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
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
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 → ---
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
Attached file testcase
Trivial testcase
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
Attached patch Patch rev. 1 (obsolete) — Splinter Review
Attachment #187323 - Flags: superreview?(jst)
Attachment #187323 - Flags: review?(jst)
Keywords: testcase
Shouldn't <form> behave the same way <form action=""> does? If so, the rv ==
NS_CONTENT_ATTR_HAS_VALUE check should go. No?
yes, <form> should be equivalent to <form action="">.
Attached patch Patch rev. 2 (obsolete) — Splinter Review
(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 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+
Attachment #187323 - Attachment is obsolete: true
Attachment #187323 - Flags: superreview?(jst)
Attachment #187323 - Flags: review?(jst)
Attached patch Patch rev. 3Splinter Review
With last comment addressed.
Attachment #187461 - Attachment is obsolete: true
Attachment #187523 - Flags: approval1.8b3?
Comment on attachment 187523 [details] [diff] [review]
Patch rev. 3

a=chofmann
Attachment #187523 - Flags: approval1.8b3? → approval1.8b3+
Checked in to trunk at 2005-06-28 16:22 PDT

-> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Flags: blocking1.8b3?
Resolution: --- → FIXED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
Depends on: 607145
Depends on: 607974
You need to log in before you can comment on or make changes to this bug.