48954 - form submission broken on relative action URIs with hashmarks or non-standard ports [form sub]

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jonathan Bartlett]

if the action attribute of the form tag points to the current page and has a
hash in it, when the submit button is clicked on, it just looks for the anchor
within the current page, instead of actually submitting the form to the server. 
For example:

<form action="this.cgi#here">
<input type=submit>
</form>

If the page you are looking at is called "this.cgi", clicking on the submit
button will not submit the form.  This behavior occurred on M17 and recent
nightly builds.  The Aug 13 build, however, would only exhibit the behavior if
the anchor was different than the one in the location bar.  For example, if the
location bar had "this.cgi#hello" and the action attribute had
"this.cgi#goodbye", the form would be submitted.  If the location bar and the
action attribute were the same, the form would not be submitted.  In the URL
given, there is a whole set of test cases you can try to see what breaks in the
current release.

Comment 1

[Peter 'Rufus' Nelson]

confirming

Comment 2

[rods (gone)]

reassigning

Comment 3

[Eric Pollmann]

What is the expected behaviour?  Should the form always be submitted in each
case?  It appears that is what Nav 4.x does...

Comment 4

[Jonathan Bartlett]

For a real-world example of the problem, go to

http://www.wolfram.com/company/opportunities/openings.cgi

and try to click on the arrows in both Nav 4 and Mozilla.

Comment 5

[Dameon D. Welch-Abernathy]

46198 seems similiar to this

Comment 6

[ckritzer (gone)]

PDT: Nominating for nsbeta3+
Reason: Perceived data loss;

Comment 7

[Kevin McCluskey (gone)]

Marking nsbeta3-. Just not enough time to fix this problem before nsbeta3.

Comment 8

[Matthias Kerkhoff]

I think there are more implications with this bug as one might see at first
glance....
The bug is _not_ restricted to ACTION URIs with relative targets to the same
page. Instead, ANY relative ACTION URI will also break form submission, if the
server runs on a non-standard port.

The typical behaviour I've noticed is, that Mozilla just does something
(indicated by the busy pointer) for 3 or 4 seconds, but nothing happens.

This bug can be caused by _any_ relative URI in the ACTION attribute. I've
seen this behaviour also with invalid ip:port combinations, but can't reproduce
it in the moment.

I've not found a workaround for this, setting BASE doesn't help, changing the
METHOD attribute is also without any effect, so I updated the summary in the
hope someone at Mozilla helps to fix this before RTM.

Comment 9

[Vladimir Ermakov]

Updating QA contact.

Comment 10

[Kevin McCluskey (gone)]

Need info: Why would someone use a # in this context?  How common is this used?

Changed nstd to non-standard in summary
CC'ing ekrock

Comment 11

[Kevin McCluskey (gone)]

The real-world example posted by Jonathan Bartlett 2000-08-16 07:08 works for me
with todays build tested on WINNT and Linux.

The other problem reported by Matthias Kerkhoff 2000-09-20 17:38 should be
reported as a separate bug.

Marking rtm-, since there isn't an example of a real world problem and there
isn't enough time before rtm to fix the remaining issues in this bug.

Comment 12

[Matthias Kerkhoff]

Re-reported as #55906.

Comment 13

[Kevin McCluskey (gone)]

Removing [NEEDINFO] from status

Comment 14

[Jonathan Bartlett]

Mostly fixed in M18 - if you go to

http://members.wri.com/johnnyb/mozilla/formanchor.cgi

you will find that all of the buttons work reliable except the second button,
which will work the _first_ time, but further clicks do not resubmit the form.

Comment 15

[Kevin McCluskey (gone)]

Setting milestone to future

Comment 16

[Koike Kazuhiko]

worksforme now.

The second testcase in <http://members.wri.com/johnnyb/mozilla/formanchor.cgi>
doesn't show any problem.

Build: 2001043008

Comment 17

[Eric Pollmann]

Marking worksforme per above comments.  Thank you Koike!

Comment 18

[Vladimir Ermakov]

The GET buttons in the testcase are still working only once... reopening

Comment 19

[Kevin McCluskey (gone)]

Bulk reassigning form bugs to Alex

Comment 20

[John Keiser (jkeiser)]

The culprit is the loader.  When we send a GET request, it acts just like a link
click or typing in the URL bar: it first checks to see if the URL is an anchor
in that document.  The proper solution to this is to add a new load type or some
load flags that say hey, this ia a form submit, we need you to load anyway.  Or
maybe said flag already exists.

Current code that actually short-circuits for anchors is
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#4089.

Comment 21

[John Keiser (jkeiser)]

There's no easy way of doing this one, as far as I can tell.  We'll have to
either modify OnLinkClick() or add a new submit form event type that can load
the URI with proper flags.

Comment 22

[Vladimir Ermakov]

wfm 2002-10-18-08-trunk

Comment 23

[Vladimir Ermakov]

verifying build 2003-02-12-08-trunk