267032 - POST data is lost when submitting a form that is embedded in a HTML email using Outlook Express 6

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[Ralf]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1

When I submit a form that is embedded in a HTML email the POST data included in
the form is not transferred to the website. This problem was confirmed by a
collegue on a different Win98 machine, also using Firefox+OE6. The problem does
not occur if the standard browser is changed to IE6 (on both machines). If you
cannot reproduce this problem I will try to submit an eml-file and php-script
that demonstrate the problem.

Reproducible: Always
Steps to Reproduce:
1. Receive a HTML email in OE6 that contains a web form.
2. Enter data (e.g. into a textarea field) in that HTML email form and submit it
3. This will open a new web browser window (Firefox, if it is set as default
internet browser), triggering a server side script to evaluate the submitted
form data
Actual Results:  
The server side website script does not receive the POST data that was
submitted. (if form-method is set GET it will work though)

Expected Results:  
The script should receive the variable(s) submitted by the POST form.

If it is an OE6 bug, then IE6 should be affected as well, shouldn't it?

Comment 1

[Ralf]

Additional bug info: The server log files indicate, that the Firefox requests
were GETs (without data however) instead of POSTs! How can this be, if the
method is set to POST in the form-tag? For IE6 the server log files show POST as
request method.

Comment 2

[Rich Willis]

I had the same problem on Windows between Outlook email to Firefox (Post data is
lost).  I verified the problem in Linux between Thurderbird to Firefox 1.0.  The
POST data is lost.  

When trying from Outlook to IE6. The post worked OK.

Comment 3

[Cedric. S.]

We experiment a probleme which might be the same or not and we found out it was
due to the mixed use of a query string in the action URL :

<form method="POST" action="action.php?param=value">
...
</form>

We found out that the form action.php is accessed two times, the first time in
POST, the second time in GET, thus given the impression that the posted data has
not been sent.

Firefox 1.0.2

Hope this helps.

Comment 4

[Ada Hsu]

Attachment: Firefox send a HTTP GET request

This attachment maybe confirm this bug's situation.
I found Firefox send a HTTP GET request to web server before the form 'post'
method assigned.

Windows 2000 pro + Firefox 1.0.4 zh_TW is my enviroment !

Comment 5

[Martin Logan]

We have an application that uses HTML forms in email - WE see little problem where the method is GET, but when we need to use POST we see similar issues.

We see this same issue with Outlook 2000, XP and 2003.

We see a POST with the correct data followed nearly instantly by GET with no data

In some instances, however, we only see the GET with no data.

This happens at client sites so I cannot realyy provide additional information. 

Comment 6

[eip]

Both POST and GET requests are transmitted from e-mail client (or any other external application) to a web browser via DDE message WWW_OpenURL (we speak about Windows here). 

The syntax can be found, for example, here:

http://graphcomp.com/info/specs/nets/ddeapi.html#WWW_OpenURL

To initiate a POST request, an external application can put data to be POSTed into 
the 5th parameter of the message, which is named qcsPostFormData in this specification. 
That is what Outlook [Express] does. 

By looking into the source code, I found that Firefox simply ignores this parameter, and treats any WWW_OpenURL message as a command to GET a page.  

The file is http://mxr.mozilla.org/mozilla1.8/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp
(there is a similar file in /toolkit/xre/ , with the same problem, but it seems it is not used in Firefox).  

Here is the code, starting from line:
===========================================
1476         if ( uType == XTYP_REQUEST ) {
1477             switch ( FindTopic( hsz1 ) ) {
1478                 case topicOpenURL: {
1479                     // Open a given URL...
1480 
1481                     // Default is to open in current window.
1482                     PRBool new_window = PR_FALSE;
1483 
1484                     // Get the URL from the first argument in the command.
1485                     nsCAutoString url;
1486                     ParseDDEArg(hsz2, 0, url);
1487                     // Read the 3rd argument in the command to determine if a
1488                     // new window is to be used.
1489                     nsCAutoString windowID;
1490                     ParseDDEArg(hsz2, 2, windowID);
1491                     // "0" means to open the URL in a new window.
1492                     if ( strcmp(windowID.get(), "0" ) == 0 ) {
1493                         new_window = PR_TRUE;
1494                     }
1495 
1496                     // Make it look like command line args.
1497                     url.Insert( NS_STRINGIFY(MOZ_APP_NAME) " -url ", 0 );
1498 #if MOZ_DEBUG_DDE
1499                     printf( "Handling dde XTYP_REQUEST request: [%s]...\n", url.get() );
1500 #endif
1501                     // Now handle it.
1502                     nsCOMPtr<nsIDOMWindow> win;
1503                     HandleRequest( LPBYTE( url.get() ), new_window, getter_AddRefs( win ) );
1504                     // Return pseudo window ID.
1505                     result = CreateDDEData( 1 );
1506                     break;
1507                 }
===========================================

Maybe it's time to implement handling of such DDE requests?  It seems like an easy task for a person who is familiar with Mozilla hacking. Unfortunately, I'm not such a person.
It's clear there is a demand for a fix, as many livejournal users, many RSS users are affected by this. 

See also this related bug for Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=242974

If/when this will be implemented, the bug #242974 can be fixed by making TB send proper DDE messages (but only in Windows).  This way there will be full interoperability between TB, FF, and other programs (including MS programs). 

Comment 7

[:Gijs (he/him)]

Moving this to the right component. I'm not sure if this is WONTFIX, but that's up to the people that take care of Toolkit.