Closed Bug 41241 Opened 24 years ago Closed 24 years ago

<form target=_foo method=post> sends POST and GET request

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: naujok, Assigned: adamlock)

References

(
URL
)

Details

(Whiteboard: [nsbeta3-][rtm-])

Attachments

(5 files)

simplified test case
144 bytes, text/html
Details
Ignore - Just a test of a form using POST
12 bytes, text/plain
Details
One way to solve the problem. Notes follow
3.87 KB, patch
Details | Diff | Splinter Review
The same changes but as a unified diff. Ready for review
3.54 KB, patch
Details | Diff | Splinter Review
Same patch without the fallback to the hidden global window
2.61 KB, patch
Details | Diff | Splinter Review 
I am building an internal project which includes an HTTP server. Certain
commands are then run internally within the server by get or post handlers.

One of the forms (full HTML to follow) is sent using a POST method. However,
Mozilla (M15) sends it using the GET method (Full HTTP headers included). This
only happens on certain forms within the project (The log-in screen works
correctly, the HTML for that follows as well.) In any case, calling GET instead
of PUT is obviously incorrect.

(The project is called NIWS 3.0 if you're wondering.)

HTML of Log-In Screen [greeting.html] (Works)
------------------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="Author" CONTENT="Jeffrey R. Naujok">
   <META NAME="GENERATOR" CONTENT="EditPlus 1.25">
   <META NAME="Description" CONTENT="Home page for NIWS 3.0">
   <link rel=stylesheet type="text/css" href="/style-sheets/NIWS3Standard.css"
title="NIWS3Standard">
   <TITLE>Welcome to NIWS 3.0!</TITLE>
</HEAD>

<BODY bgcolor="white" onLoad="document.LoginForm.UserName.focus();">
<table width=600 border=0 cellpadding=0 cellspacing=0>
    <tr>
        <td align=left width=200 class=loginMenu valign=top>
            <b>NIWS 3.0</b><br>
            <hr width=80% height=2 color=#E0E0E0>
            Login to NIWS<br>
            <a href="/newuser/index.html">Get a NIWS Account</a><br>
            <hr width=80% height=2 color=#E0E0E0>
            <a href="/intro/whatis.html">What is NIWS?</a><br>
            <a href="/intro/whatsnew.html">What's new in 3.0?</a><br>
            <hr width=80% height=2 color=#E0E0E0>
            <a href="http://niwsroom.mcit.com">The NIWSROOM</a><br>
            <hr width=80% height=2 color=#E0E0E0>
            <a href="/documents/support.html">Support</a><br>
            <a href="/documents/comments.html">Comments</a><br>
            <hr width=80% height=2 color=#E0E0E0>
            <a href="/documents/browsers.html">Supported Browsers</a><br>
            <hr width=80% height=2 color=#E0E0E0>
            <a href="/documents/legal_information.html">Legal Information</a><br>
            <br><br>
            <div class=infoText>
            Thanks for coming to the NIWS system!<br>
            NIWS has been developed entirely within the MCI WorldCom corporation
using no outside vendor products.<br>
            </div>
        </td>
        <td align=center valign=center>
            <h1>Welcome to the NIWS 3.0 System</h1>
            <br>
            <hr width=80% color=#E0E0E0>
            <h2>Please Log-in</h2>
            <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
                <TR>
                    <TD ALIGN=CENTER NOWRAP WIDTH="400">
                        <TABLE BORDER=2 CELLSPACING=0 CELLPADDING=0 WIDTH="100%"
class=loginFrame>
                            <TR>
                                <TD ALIGN=CENTER WIDTH="100%" class=loginFrame>
                                    <FORM action="exec/LoginTest" method="POST"
name="LoginForm" target="_top">
                                    <br>
                                    <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0
WIDTH="100%" class=loginFrame>
                                        <TR>
                                            <TD ALIGN=RIGHT WIDTH="300"
class=loginFrame>
                                                <font face=arial>
                                                    <nobr>
                                                        User ID:&nbsp;<INPUT
type="text" size="15" name="UserName">
                                                    </nobr>
                                                    <br>
                                                    <nobr>
                                                        PassWord:&nbsp;<INPUT
type="password" size="15" name="PassWord">
                                                    </nobr>
                                                </font>
                                            </TD>
                                            <TD ALIGN=CENTER WIDTH="125"
class=loginFrame>
                                                <INPUT type="submit"
name="Login" value="Login">
                                                <br><br>
                                                <INPUT type="reset" name="
Clear" value="Clear">
                                            </TD>
                                        </TR>
                                    </TABLE>
                                    </FORM>
                                </TD>
                            </TR>
                        </TABLE>
                    </TD>
                </tr>
            </TABLE>
            <br><a href="/forgotpassword/index.html">Forget your password?</a><br>
        </td>
    </tr>
</table>
<table width=600 border=0 cellpadding=0 cellspacing=0>
    <tr>
        <td class=copyrightBar align=center valign=center>
            Copyright &copy; 2000, MCI WorldCom Corporation. All Rights Reserved.
        </td>
    </tr>
</table>
</BODY>
</HTML>


HTML of Circuit Long-Route Form [index.html] (Does not work)
--------------------------------------------------------------------------------
<!-- Data was parsed by NIWS 3.0 -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
    <META NAME="Author" CONTENT="Jeffrey R. Naujok">
    <META NAME="GENERATOR" CONTENT="EditPlus 1.25">
    <META NAME="Description" CONTENT="Circuit Long Route Report">
    <link rel=stylesheet type="text/css" href="/style-sheets/NIWS3Standard.css"
title="NIWS3Standard">
    <title>NIWS: Circuit Long-Route Report</title>
    <script language="javascri
*** Bug 41242 has been marked as a duplicate of this bug. ***
reporter: can you please ensure that this problem is still occurring on the 
latest nightly builds? you mentioned that you saw it in M15, which is old by now
With last night's build (6/4/2000), I'm still getting the same error.

Please note that this only happens if the target of the form is "_blank". If I 
use "_top", or a named frame, it doesn't happen.

[GET /exec/DoReport HTTP/1.1]
[Host: stutz.mcit.com:8080]
[User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m16) Gecko/20000604]
[Accept: */*]
[Accept-Language: en]
[Accept-Encoding: gzip,deflate,compress,identity]
[Keep-Alive: 300]
[Connection: keep-alive]
[] 

Setting bug to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
reassigning
Assignee: rods → pollmann
Status: NEW → ASSIGNED
Summary: Form POST is sent with HTTP GET method instead of POST → <form target=_blank method=post> sends GET request
Attached file simplified test case — 

    
    

    
  
This behaviour will happen regardless of the target, as long as it is not an 
existing window/frame, and thus causes a new one to open.

We actually send out *two* requests to the server.  The first is correctly a 
POST, fired from: nsWebShell::HandleLinkClickEvent()
The response seems to be dropped on the floor in a messy way, as we get:

###!!! ASSERTION: OnDataAvailable fired after OnStopRequest: 'mOnStopFired == PR
_FALSE', file d:\builds\pollmann\mozilla\netwerk\protocol\http\src\nsHTTPRespons
eListener.cpp, line 1227
###!!! Break: at file d:\builds\pollmann\mozilla\netwerk\protocol\http\src\nsHTT
PResponseListener.cpp, line 1227

The second is a GET request with no data, encoded or posted.  This is sent from:
GlobalWindowImpl::OpenInternal where we call newDocShell->LoadURI(uriToLoad, 
loadInfo);

My best guess is that we are also sending two requests for <a 
target="_foo">bar</a> too because it uses the same code path.  Nobody probably 
notices because they would both be GET's

Since the problem seems to be in GlobalWindowImpl and DocShell, giving this one 
to you Adam.  If I can help, please let me know!
Assignee: pollmann → adamlock
Status: ASSIGNED → NEW
Summary: <form target=_blank method=post> sends GET request → <form target=_foo method=post> sends POST and GET request

    
    

    
  
Docshell will only use "POST" if there is some postdata to post. Do any of these 
forms have no data?

Regarding "PUT" - I'm rather worried that I can't find any reference to this at 
all! I have a horrible feeling that docshell has not support for it at all.

Does anyone know any different?

    
    

    
  
What am I smoking? There's no such protocol as "PUT" - just "GET" AND "POST".

    
    

    
  
heh...I dunno what you're smoking but it's either really powerful or yer takin' 
a lot of it.

(I also noticed that your testcase only seems to consist of the words "Hello 
World"...was that intentional?)

    
    

    
  
Adam, the problem is not with POST in general, or forms, but a POST request that 
has a target set for a window that does not exist yet.  The problem is that two 
requests are sent.

1) Correctly a post, sends all the right data.
2) When the new window opens to display the results, it sends a second request.  
This second request is a GET.  This is the bad one.


    
    

    
  
Yes the test case was intentional :) I was using the submit attachment CGI to 
test Mozilla's POST behaviour.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Target Milestone: --- → Future

    
    

    
  
minusing. although this is serious. the embedding plate is full.
Whiteboard: [nsbeta3-]

    
    

    
  
My only problem with you marking this as a "future concern" is that the product 
I'm working on where I originally found this problem represents over 1000 users 
at MCI WorldCom. They're already itching to find a reason to make MicroDolts 
their official browser, and since we open a new blank window to provide 
reporting results /every time/, this will give them the excuse to drop Netscape 
entirely from MCI WorldCom. That's 50,000 users. Still seem like this should be 
shelved?

    
    

    
  
*** Bug 51259 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 51259 has been marked as a duplicate of this bug. ***

    
    

    
  
Updating QA contact.
QA Contact: ckritzer → vladimire

    
    

    
  
Adding rtm keyword. 
Keywords: rtm

    
    

    
  
*** Bug 49494 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 53019 has been marked as a duplicate of this bug. ***

    
    

    
  
Changing OS to All. 
This bug is crashing linux build 2000-10-03-09-MN6 and
crashing Mac build 2000-09-29-11-MN6.
OS: Windows NT → All

    
    

    
  
rtm-, outside the specific environment where this was discovered it seems very 
unlikely to be hit.  If you are working on a patch, please update the bug.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]

    
    

    
  
*** Bug 59431 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 60388 has been marked as a duplicate of this bug. ***

    
    

    
  
cc'ing self...

selmer@netscape.com: with all the dupes, I would think it would be safe to say
that this bug will be found in other areas outside the reporters development
environment...

I use target="new" to open a new form for the users, posting the information
that they have entered into my screen. This bug is a pain to work around.

My current hack/workaround is to open a new HTML form using window.open. In my
case, the elements to be submitted are always the same, so I have hard coded
them in this new form. I set these element's values via Javascript and then do a
javascript form.submit(). This seems to work well, although future maintainers
of this code will wonder what drugs I was on.

In more complicated circumstances, doing some form of innerHTML tweaking could
prolly get this workaround to be more robust...

<RANT type="frustration">
In my opinion, this is just another bug that makes it hard to develop for
Mozilla. Netscape needs to realize that without developers actively supporting
their platform, they'll continue to tank in market share, especially in
corporate environments. Making it hard for developers to do simple things will
continue to drive them away which will speed up the spiral...
</RANT>

    
    

    
  
Is bug 59547 a dupe of this bug?
If so, there are a lot of instances this bug is causing pain and confusion.

    
    

    
  
*** Bug 59547 has been marked as a duplicate of this bug. ***

    
    

    
  
To clarify, it looks like 59547 is a dup, but the other instances are probably
duplicates of bug 27006.

    
    

    
  
It looks to me like the channel loading and window creation behaviour is a bit 
screwy. This stack shows where the newly created "_blank" target window is told 
to load the URI:

nsDocShell::DoURILoad(nsDocShell * const 0x05e26300, nsIURI * 0x05a41720, nsIURI 
* 0x00000000, nsISupports * 0x00000000, int 0x00000000, int 0x00000000, const 
char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000) 
line 3095
nsDocShell::InternalLoad(nsDocShell * const 0x05e26300, nsIURI * 0x05a41720, 
nsIURI * 0x00000000, nsISupports * 0x00000000, int 0x00000000, int 0x00000000, 
const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 
0x00000000, unsigned int 0x00000001, nsISHEntry * 0x00000000) line 3005 + 47 
bytes
nsDocShell::LoadURI(nsDocShell * const 0x05e26300, nsIURI * 0x05a41720, 
nsIDocShellLoadInfo * 0x00000000, unsigned int 0x00000000) line 429 + 65 bytes
GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x0455b590, JSContext * 
0x0455b370, long * 0x010b0f48, unsigned int 0x00000002, int 0x00000000, 
nsIDOMWindowInternal * * 0x0012f6d8) line 3132
GlobalWindowImpl::Open(GlobalWindowImpl * const 0x0455b594, JSContext * 
0x0455b370, long * 0x010b0f48, unsigned int 0x00000002, nsIDOMWindowInternal * * 
0x0012f6d8) line 2067
nsBrowserContentHandler::HandleContent(nsBrowserContentHandler * const 
0x05a418f0, const char * 0x05a41930, const char * 0x01e9f348, const char * 
0x05a39740, nsISupports * 0x045530b0, nsIChannel * 0x05a39a60) line 1857 + 84 
bytes
nsURILoader::DispatchContent(nsURILoader * const 0x017a8e80, const char * 
0x05a41930, int 0x00000007, const char * 0x05a39740, nsIChannel * 0x05a39a60, 
nsISupports * 0x00000000, nsIURIContentListener * 0x04553030, nsISupports * 
0x045530b0, char * * 0x0012f96c, nsIURIContentListener * * 0x0012f974, int * 
0x0012f964) line 1027 + 53 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x05a39a60, nsISupports * 
0x00000000) line 310 + 165 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x05a39780, 
nsIChannel * 0x05a39a60, nsISupports * 0x00000000) line 241 + 16 bytes
nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x05a39620, 
nsIChannel * 0x05a39a60, nsISupports * 0x00000000) line 1131
nsHTTPServerListener::FinishedResponseHeaders() line 1056 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x05a37f50, 
nsIChannel * 0x05a3fd54, nsISupports * 0x05a39a60, nsIInputStream * 0x05a370c0, 
unsigned int 0x00000000, unsigned int 0x00000000) line 427 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x05a407f0) 
line 407 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x05a40800) line 92 + 12 bytes
PL_HandleEvent(PLEvent * 0x05a40800) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00abfb10) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00140c90, unsigned int 0x0000c115, unsigned int 
0x00000000, long 0x00abfb10) line 1054 + 9 bytes
USER32! 77e71820()
00abfb10()

The interesting stuff starts to happen in 
nsBrowserContentHandler::HandleContent. This is what gets called when data 
starts to arrive. This method pops a few things such as the URL and the window 
target into a Javascript context and tells the global window manager to open the 
window. It then aborts the original channel!?

Next, the global window manager creates the new window and docshell (because it 
doesn't exist) and tells the docshell to load the URI provided in the JS context 
when HandleContent called to open the window.

So there are a couple of weird things happening here:

1. The original POST operation is aborted. Why? Can a channel to be bound to a 
newly created docshell?
2. The global window methods Open & OpenInternal are not passed channel or 
postdata information so they open the new window as a GET request.

If it's possible to attach the original channel to a docshell then that should 
be done. The open methods on the global window should have channel arguments and 
the browser content handler should pass that over rather than aborting the 
original binding. This stops two URL requests being submitted including the 
erroneous second GET operation.

    
    

    
  
The attachment solves the "create one POST channel, open a new window when 
content arrives, create a GET channel and abort the POST channel" issue.

It does this by creating the new window much earlier. It creates the new window 
just as the URI loader object is about to open the first POST channel while it's 
finding the window context it should be associated with. The new code creates 
the new window, sets the window context and changes the target to itself so the 
channel content goes straight into the new window and doesn't hit the old code. 

It works but I'm not familiar with the nuances of script contexts to know if I 
may have broken something else, such as when I create a new window with an empty 
string URI in the JS context. Is that safe?

I'm also unsure about the dependencies I've introduced. Now the uriloader 
project depends on the JS library and drags some DOM window stuff in too. Is 
that safe? Should this "create a new window" code I've introduced really be a 
service in the DOM library?

Comments please.

    
  
Target Milestone: Future → mozilla0.8

    
  
Blocks: 46893

    
    

    
  
Looks like this is probably a good thing to me.  CC'ing Rick Potts though,
because he has more knowledge of URI loading...

    
    

    
  
Browser: Mozilla M18, dated 05 January 2001. (It was the last build for the 
moment).
Reports itself as: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010104

I found the similar problem when requesting a HTML document via the POST when
the server requires authorization (note no "target" attribute is used!). The 
original HTML and the exact HTTP headers follow:
------------------------------------------------
[The file enter.htm]:
<html>
<head>
<TITLE>APCIS2000: Entrance</TITLE></head>
<body BGCOLOR="#000066" BACKGROUND="/apcis/imgs/bkgrMainMenu.gif">
<TABLE><TR><TD width=750>
<nobr>
<table BORDER="0" WIDTH="100%">
  <tr>
    <td COLSPAN="3"align="center"><font SIZE="-2" FACE="Arial" COLOR="#FFCCCC">
                The Entrance page
        </font> </td>
  </tr>
  <tr>
    <td><img SRC="/apcis/imgs/Globe.gif" WIDTH="113" HEIGHT="105" 
ALIGN="bottom"></td>
    <td></td>
    <td><p ALIGN="right"><font SIZE="+2" 
COLOR="#000066"><b><i>APCIS2000&nbsp;&nbsp;</i></b></font></td>
  </tr>
  <tr>
    <td COLSPAN="3"><p align="center"><font SIZE="+2" COLOR="#FF9999">
                Asia - Pacific<br>
                Computerized Information System<br>
                on Port State Control<BR>
    </font></td>
  </tr>
</table>
<NOSCRIPT>
<table BORDER="0" BGCOLOR="#000066" CELLSPACING="12" CELLPADDING="10" 
WIDTH="100%">
  <tr><td align="center"><b><font SIZE="+2" COLOR="#ED4E56">
        Warning! JavaScript is disabled.<br>
    <i>APCIS2000</i> requires JavaScript for its operations.<br>
    Please, <a HREF="jsenabling.htm"><font COLOR="#9999FF">enable 
JavaScript</font></a> in your browser and reload this page.
  </font></b></td></tr>
</table>
</NOSCRIPT>
<form ACTION="/apcis/FMPro" METHOD="post" name="RegForm">
  <input type="hidden" name="-DB" value="Access.fp3">
  <input type="hidden" name="-Lay" value="web">
  <input type="hidden" name="-Format" value="preload.htm">
  <input type="hidden" name="-Error" value="oops.htm">
  <input type="hidden" name="UserIP" value="192.168.0.101">
  <input type="hidden" name="UserName" value="testUser">
  <input type="hidden" name="Key" value="33469064753">
  <input type="hidden" name="-New" value="">
</form>
<DIV ALIGN="CENTER"><BR><BR>
   <A HREF="javascript:document.RegForm.submit()" >ENTER</A>
<BR><BR></DIV>
<table BORDER="0" BGCOLOR="#000066" CELLSPACING="0" CELLPADDING="2" WIDTH="100%"
BACKGROUND="/apcis/imgs/tblbkgrMainMenu.gif">
  <tr>
    <td>
            <p ALIGN="right"><b> <a HREF="mailto:support@apcis.tmou.org"><font 
SIZE="-1" FACE="Arial" COLOR="#000066">mail
              to tech support</font></a><font SIZE="-1" FACE="Arial" 
COLOR="#000066">&nbsp;&nbsp;
              </font></b>
          </td>
  </tr>
</table>
<BR>
<table BORDER="0" ALIGN="CENTER">
  <tr>
    <td ALIGN="center"><font COLOR="#FF9999" FACE="Arial">Optimized for screen 
resolution = 800x600</font></td>
  </tr>
</table>
</nobr>
</TD></TR></TABLE>
</body>
</html>
--------------------------

[Exact HTTP headers]:

{First Request}:
POST /apcis/FMPro HTTP/1.1
Referer: 
http://127.0.0.1:8000/apcis/FMPro?-db=access.fp3&-lay=web&-format=enter.htm&-tok
en=FrVTqX126zCwHsz&-view
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010104
Accept: */*
Accept-Language: ru,en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 129

-DB=Access.fp3&-Lay=web&-Format=preload.htm&-Error=oops.htm&UserIP=%25UserIP%25&
UserName=%25UserName%25&Key=FrVTqX126zCwHsz&-New=

{Response}
HTTP/1.0 401
Server: FileMakerPro/4.0
WWW-Authenticate: Basic realm="Database access.fp3"
Content-type: text/html

{Second request}
GET /apcis/FMPro HTTP/1.1
Authorization: Basic dGVzdHVzZXI6dGVzdA==
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010104
Accept: */*
Accept-Language: ru,en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive

{Response}
HTTP/1.0 200 OK
Server: FileMakerPro/4.0
MIME-Version: 1.0
Content-type: text/html

<HTML><HEAD>
   <TITLE>Unexpected Error</TITLE>
<BODY>
 <H1>Unexpected Error: No arguments passed!</H1>
</BODY>
</HTML> 
-------------------------------------------------
Note that both Netscape 4.xx, and MSIE 5 have no such a problem.

    
    

    
  
Hmm I'm nervous about adding uriloader dependencies we add with this patch.
Reading Adam's comments I see he's nervous about that too.

Can anyone thing of any other way we could get the same behavior without adding
these dependencies? I can't think of anything off the top of my head.

    
    

    
  
I forgot to cc myself after I made my comments. 

    
    

    
  
Nominating for nsbeta1
Keywords: nsbeta1

    
    

    
  
The code itself looks good to me. Do you need to change any Mac or unix projects
now that the uriloader needs to link with JS?

Also, about the hidden window part (and the appshell service), is this part
necessary? I'm trying to think if we could get in a state where we are running a
url with a _new or  _blank window target that didn't originate from another
window.....

    
    

    
  
*** Bug 67433 has been marked as a duplicate of this bug. ***

    
    

    
  
The mac project will need updating, Unix should be fine since it links to js 
already.

I've taken out the hidden window fallback code and it seems to function 
correctly. I can't think of a way that a "_blank" target window could be opened 
without a context so this is probably a good removal.

Scott, please sr the new attachment which follows.

    
    

    
  
since the hidden window code has been taken out, you should be able to remove:

+#include "nsIAppShellService.h"
+#include "nsAppShellCIDs.h"
+
+static NS_DEFINE_CID(kAppShellServiceCID, NS_APPSHELL_SERVICE_CID);


sr=mscott if you take those lines out...

    
    

    
  
Thanks Scott, fix is checked in now
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Verifying on builds
Windows 98: 2001-02-06-08-Mtrunk 
Linux RedHat6.2: 2001-02-06-08-Mtrunk
MacOS 8.x: 2001-02-05-10-Mtrunk


Status: RESOLVED → VERIFIED

    
    

    
  
Is this really fixed in the latest nightlies?
I see in some sites Mozilla is sending two requests when document.FOO.submit()
is used to submit a form as in this example below.
<html>
	<head>
		<meta http-equiv="content-type" content="text/html;charset=x-sjis">
		<title></title>
	</head>
			<a href="javaScript:document.yourForm.submit();">submit</a></p>
					<form name="yourForm" action="http://www2.france.co.jp/france/kensaku.asp" 
method="post">
					<input type="hidden" name="SHINKAN" value="1"><input type="hidden" name="DISPMODE"
value="TEXT">
		</form>
	</body>
</html>
 

    
    

    
  
The above example is now WFM in 2001020908 build.

    
    

    
  
Browser: Mozilla 0.8, dated 12 February 2001. (It was the last build for the 
moment).
Reports itself as: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010212

The problem has not been fixed. I've got the same result (HTTP headers follow):
[Request1]
POST /apcis/FMPro HTTP/1.1
Referer: 
http://127.0.0.1:8000/apcis/FMPro?-db=Access.fp3&-lay=web&-format=enter.htm&-tok
en=tst&-view
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010212
Accept: */*
Accept-Language: ru, en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
Content-type: application/x-www-form-urlencoded
Content-Length: 117

-DB=Access.fp3&-Lay=web&-Format=preload.htm&-Error=oops.htm&UserIP=%25UserIP%25&
UserName=%25UserName%25&Key=tst&-New=
[Response1]
HTTP/1.0 401 Unauthorized
Server: FileMaker Pro/4.0
WWW-Authenticate: Basic realm="Protected resource"

[Request2]
GET /apcis/FMPro HTTP/1.1 //POST SHOULD BE HERE INSTEAD OF GET!!!!!!!
Authorization: Basic b3dsLXRzdDpvd2w=
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010212
Accept: */*
Accept-Language: ru, en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
[Response2]
HTTP/1.0 200 OK 
MIME-Version: 1.0
Server: APCIS Entrance Gateway/1.2
Content-Type: text/html

<HTML>
<HEAD>
<TITLE>Unexpected Error</TITLE>
</HEAD>
<BODY>
 Unexpected Error: No arguments passed!
</BODY>
</HTML>

I found the problem when requesting a HTML document via the POST when
the server requires authorization (note no "target" attribute is used!)

Thanks.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
The original problem which was to do with target windows is fixed so I'm 
remarking it as such. I have opened bug 68666 to deal with the Javascript submit 
problems.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
verifying
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 65982 has been marked as a duplicate of this bug. ***

    
    

    
  
This only fixes the problem for target="_new" and target="_blank".  The problem
remains for target="newwindow" when there is no existing window named
'newwindow'.  See bug 72491.

    
    

    
  
I'm experiencing something like this when submitting forms to a PerlEx script 
(similar to mod_perl, but for Windows, from activestate.com). 

I'll submit a form to a very simple PerlEx script that simply prints out the 
variables that were passed to the script, as well as the %ENV variables. It 
shows as a GET, and no data coming from the browser.

Then I hit the back button, submit the form again, and it works correctly this 
time, showing as a POST and all the form variables come through OK. I am using 
a recent version of CGI.pm to parse the form input.

I have duplicated this bug on:

- Mozilla 0.8 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) 
Gecko/20010215)

- Netscape 6.0.1 (where I first got complaints of this happening)

- Mozilla Nightly Build as of 3/30/2001 (Mozilla/5.0 (Windows; U; Windows NT 
5.0; en-US; 0.8.1))

This is causing us serious problems. We are going to have to recommend that our 
users not use Netscape 6 if this doesn't get fixed soon. (Of course, it would 
be nice if we could point them to a new build of Mozilla which works, as a 
replacement, instead of MSIE.)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
  
Target Milestone: mozilla0.8 → mozilla0.9

    
  
Blocks: 72491

    
    

    
  
I'm closing this bug in favour of bug 72491.

This bug dealt with problems with _blank and _new which were fixed. The other 
bug deals with problems using GET/POST to named windows. Please CC yourself to 
the other bug.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
verifying fixed on build 2001-04-10-04-trunk Windows 98
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: