User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040229 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040229 Firefox/0.8.0+ When I receive html mail in thunderbird that has an html form, the form submission is not passed correctly if the form uses method=post. Reproducible: Always Steps to Reproduce: 1. 2. 3.

can't find an earlier report of this for Thunderbird, but I might have missed it. obviously tricky for Thunderbird to do POST form submission because it's not a browser.

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

Would it be possible to convert POST to GET? I know some foms would be broken due to that, but it wouldn't be any more broken than the current version but would fix for some forms. (this is an annoyance in trying to convert from Mozilla to Thunderbird. I have not tried Outlook behavior for this to see if it allows form POST) Also, since this is a regression from the behavior of the Mozilla Suite that this will replace in the future, I believe this is a minor bug, not an enhancement.

dup of bug 218976 ?

Darin, any thoughts on this, or on who might have an idea? Would it be very hard or at all possible for tbird to handle the form submit itself?

I don't know the form submission code all that well, but it seems odd to me that it is not being invoked already by Gecko. Perhaps some debugging would reveal the problem.

(In reply to comment #6) > but it seems odd to me that > it is not being invoked already by Gecko. I'm sure that's because gecko never even gets a chance. http is not an exposed protocol for thunderbird. when you click on an http url, the uriloader sends it straight to the OS. We don't do anything with it.

yes, I should have said that when we launch the external browser, we can only pass in a url, and the form data doesn't get passed into the external browser. And since we can't control the external browser, it seems that the only way to get this working from tbird is to have tbird do it itself, via gecko.

oh, right... of course. what is the ideal result? are you hoping to have tbird download the resulting html file and then have the browser load that html file from the local filesystem? (using file:// URLs instead of http:// URLs has JS security problems since the security principal of the page is no longer that of the website.) or do you want tbird to load the result of the form post into some sort of window within tbird? it might be neat to show the results of a form post in a popup window or something. do any other mailers support html form post?

I'm not sure what the ideal result would be - if it doesn't open too big a can of worms, I think *not* launching a browser would be nice, but we're mostly interested in being able to get the submit itself working. We don't know if any other html mailers support this - we're pretty sure OE doesn't, and I suspect neither does Outlook. I'd bet Eudora doesn't either...

If I understand correctly, we'd need a mechanism for thunderbird to get a crack at the url, somehow figure out if the http url was a form post (I assume that's not hard). If it's not a form post, we'd need to kick it back to the uri loader; otherwise, we'd need to run the url through gecko and display the results in a little wrapper html window. How hard does all this sound?

lot's of unknowns for me.. i couldn't say how hard it would be to implement it :-/

well this is a dupe of 218976 - my fault for missing that. but now you guys have started discussing here, I guess this should be duped backwards.

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

With the new RSS reader in Thuderbird this is going to become increasingly requested. e.g. if you read Slashdot through its RSS feed then when the stories are displayed in Thunderbird it is not possible to login to your account and therefore have your default filter settings on comments. For the whole login process to work inside Thuderbird would require cookies too. So the ideal solution would be. Submit a POST request and reload the resulting page within the same window in Thunderbird. Accept the cookie and remain logged into slashdot so that when you read the next story it remembers who you are.

This is of particular interest to me as this is my main interface to LiveJournal comments. Perhaps LJ can look into doing this as a GET.

The probem seems to be within Thunderbird's handling of the form. When I attempt to submit the form from Thunderbird, it only sends the URL to the browser, without any other information. Method for testing: Create a shell script that prints all inputs: #!/bin/bash echo $*>>test.out Change Thunderbird to invoke script for all e-mail: user_pref("network.protocol-handler.app.http", "/path/to/script/file.sh"); Attempt to submit form, receive: http://www.example.url/form_action_url.html Expect: http://www.example.url/form_action_url.html?form_data=test&other_stuff=stuff (Or something similar, where the data is embedded into URL.) This could fix the problem for websites that would allow GET requests.

>Expect: >http://www.example.url/form_action_url.html?form_data=test&other_stuff=stuff >(Or something similar, where the data is embedded into URL.) why do you expect that, for a POST method? this url would correspond to a GET method.

(In reply to comment #18) > >Expect: > >http://www.example.url/form_action_url.html?form_data=test&other_stuff=stuff > >(Or something similar, where the data is embedded into URL.) > > why do you expect that, for a POST method? this url would correspond to a GET > method. That would be a solution that would be the least-surprise to a user attempting to do a submission from the form within Thunderbird. Creation of new embeded Gecko window would be a surprise for user because it would not be their browser. (ie. They can't continue browsing, change any information or have their extensions) That is unfortunately not a solution that allows for full conformance to the request of the HTML. But from my understanding, it would be impossible to conform to the HTML and yet not surprise the user. (Unless there's some other method of passing the URL other than command line paramater - ie. what the suite was doing and probably what Outlook+IE does)

I think the best way for the end-user is going to be to have Thunderbird interact with Firefox to post the form, but how practical is the interaction? Of course, there's going to be the problem of people who aren't using Firefox (There's bound to be one or two!). How does OE -> Firefox handle? I can't test it, as I don't have OE on any of my machines anymore, but I'll see if I can get it reinstalled on one for testing. No idea on the other platforms though. The other solution is as proposed, have Thunderbird process it internally in a Gecko window (preview window / new window?), and handle it from there. But that may get confusing to users, and leave them open to browing through the TB window, which would be undesirable... Not sure how to proceed on this one, and I haven't a clue where to start on it myself personally. It also doesn't say anything about other operating systems. Perhaps some sort of internal XUL document format to be passed to Firefox if detected? (Sorry if this lot's just useless wild stabbing, just looking to try and give ideas.)

I think the best way for the end-user is going to be to have Thunderbird interact with Firefox to post the form, but how practical is the interaction? Of course, there's going to be the problem of people who aren't using Firefox (There's bound to be one or two!). How does OE -> Firefox handle? I can't test it, as I don't have OE on any of my machines anymore, but I'll see if I can get it reinstalled on one for testing. No idea on the other platforms though. The other solution is as proposed, have Thunderbird process it internally in a Gecko window (preview window / new window?), and handle it from there. But that may get confusing to users, and leave them open to browing through the TB window, which would be undesirable... Not sure how to proceed on this one, and I haven't a clue where to start on it myself personally. It also doesn't say anything about other operating systems. Perhaps some sort of internal XUL document format to be passed to Firefox if detected? (Sorry if this lot's just useless wild stabbing, just looking to try and give ideas.)

I just downloaded Tbird 1.0 to try it out and it apparently still has this bug. I'd really like to switch to Thunderbird, but I won't until this bug is fixed. Is anyone working on it?

Does the GRE have an equivalent of DDE? I have a feeling that's the way OE/IE do it... but it's how to get the data across. Tempfiles are messy and can be unreliable, but a cross-platform implementation needs sorting out to solve the issue. Unfortunately, I've no idea how to do it - hacking the internals of Mozilla isn't my forté yet :(

(In reply to comment #20) > I think the best way for the end-user is going to be to have Thunderbird > interact with Firefox to post the form, but how practical is the interaction? Of > course, there's going to be the problem of people who aren't using Firefox > (There's bound to be one or two!). How does OE -> Firefox handle? I can't test > it, as I don't have OE on any of my machines anymore, but I'll see if I can get > it reinstalled on one for testing. No idea on the other platforms though. > The other solution is as proposed, have Thunderbird process it internally in a > Gecko window (preview window / new window?), and handle it from there. But that > may get confusing to users, and leave them open to browing through the TB > window, which would be undesirable... > Not sure how to proceed on this one, and I haven't a clue where to start on it > myself personally. It also doesn't say anything about other operating systems. > Perhaps some sort of internal XUL document format to be passed to Firefox if > detected? > (Sorry if this lot's just useless wild stabbing, just looking to try and give > ideas.) OE/Firefox doesn't works with POST, like Thunderbird, but OE/IE works fine.

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

I have no problems POSTing forms with Mozilla mail. Why the problem with Thunderbird? It doesn't seem to me that it should be that hard to get right. I find it interesting that there was only one vote for this bug - is no-one using email creatively?

>I have no problems POSTing forms with Mozilla mail. Why the problem with >Thunderbird? It doesn't seem to me that it should be that hard to get right. We're not talking about Mozilla mail. Unilke the Mozilla Suite, which has an e-mail client and a web browser in one application, Firefox and Thunderbird are separate applications. There doesn't exist (to my knowledge) a standard cross-platform method of passing large amounts of data between two programs. In Firefox, all we can really do at this point is pass a URL to Firefox via the command line. We don't have any fancy interprocess communication available yet. (See Comment 8).

(In reply to comment #27) >There doesn't > exist (to my knowledge) a standard cross-platform method of passing large > amounts of data between two programs. > > In Firefox, all we can really do at this point is pass a URL to Firefox via the > command line. We don't have any fancy interprocess communication available yet. > (See Comment 8). Yep, I can see that could be a problem :-) How about generating a temp file with some javascript that when that is opened in the browser forwards the POST data? Some similar trickery should be workable. gen - post12345.html, firefox.exe %tmpdir%/post12345.html

Following on from my suggestion on generating a tempfile, and also picking up (again) on Paul's comment regarding inter app communication, it struck me that a browser does indeed provide such a protocol. Rather than generating a tempfile, the invoked app could be: firefox.exe http://localhost:<thunderbirdport>/post1234.html ...and generate the data internally rather than writing to an external file. The port could be created dynamically and closed after serving up the content.

What about to write (for temporary use) an extension, that saves a mail with post form and launching FireFox or IE to process the file? Or other idea: Changing submit buttons (that in post method forms) in mail to such view: <input type=button value='Submit' onclick='submitform();'> And a function is: function submitform() { popup = window.open('', 'result'); popup.document.open(); popup.document.writeln('<html>'); popup.document.writeln('<body onload=\"mailform.submit()\">'); popup.document.writeln('<form name=\"mailform\" action=\"somehostandpath\" method=\"POST\">'); popup.document.writeln('FORM');//There is content of form in the mail popup.document.writeln('</form>'); popup.document.writeln('</body>'); popup.document.close(); popup.focus(); } I think it is good idea for a while.

(In reply to comment #30) > Or other idea: > Changing submit buttons (that in post method forms) in mail to such view: > <input type=button value='Submit' onclick='submitform();'> > > And a function is: > [code] > I think it is good idea for a while. Not a bad idea - but what about having Thunderbird process the the POST request, save the result, and passing the request via a command to FF? For example: 1. Thunderbird recieves e-mail with form enclosed. 2. User fills out form, clicks submit button. 3. Thunderbird processes this internally, saving the resulting data to a file. 4. Firefox is called, with an "IPC command" switch, advising it of where the data would normally be sent to, and the returned data from the site. (e.g. firefox.exe /IPCcommand:ProcessForm /data:c:\temp\data.tmp /site:http://www.somesite.com/formprocess.php) 5. Firefox loads, shows existing site in URL bar (but with note to show URL encoded form - perhaps a red bar, like the yellow one for secure, and/or perhaps asking the user before confirming), displays data from the TB post, and the user can then continue to navigate. Any appropriate cookies would also need to get sent across though in the process. This approach however has a couple of issues: 1. Possibility of phishing-type attacks, with maliciously constructed forms 2. Possible spam abuse 3. The data processed by Thunderbird wouldn't have the cookies for Firefox. Another possible approach: Not a bad idea - but what about having Thunderbird process the the POST request, save the result, and passing the request via a command to FF? For example: 1. Thunderbird recieves e-mail with form enclosed. 2. User fills out form, clicks submit button. 3. Thunderbird sends the form to a file with the form data filled in. 4. Firefox is called, with an "IPC command" switch, advising it of where the data is to be be sent to (e.g. firefox.exe /IPCcommand:ProcessForm /data:c:\temp\data.tmp). 5. Firefox loads, shows existing site in URL bar (but with note to show URL encoded form - perhaps a red bar, like the yellow one for secure, and/or perhaps asking the user before confirming), displays data from the TB post, and the user can then continue to navigate. All relevant cookies are already present. Approach 2 is less likely to be abused, but will need some consideration before continuing.

You don't want to save the form submission results to a local file and render that in a browser because that would be letting remote scripts have access to your filesystem. Instead, the approach of having thunderbird open a server socket on a random localhost port sounds much more reasonable from a security point of view.

(In reply to comment #32) > You don't want to save the form submission results to a local file and render > that in a browser because that would be letting remote scripts have access to > your filesystem. Instead, the approach of having thunderbird open a server > socket on a random localhost port sounds much more reasonable from a security > point of view. I must admit, it does seem a good idea. Either that, or some sort of standard Gecko port? Either way, it is better than actual local files - basically a pipe between the applications. However, I'd still be concerned on the FF pickup side - it'd have to be carefully done to avoid abuse.

Socket solving sounds good, but is it a bit complex? Or will the user system stable during opening server socket? I don't know much about this, but I feel, that there will be some incompatibility with different systems. JavaScript is platform independent and doesn't need something extra. TB can hadle it. And it's security is defines by security of JavaScript itself. JavaScript in addition is compatible with IE, so it can provide both TB->IE and TB->FF links (or any other), when the OE can work only with IE. Any spam or abuse issues can be hadled too, we can make, that FF will show all the data to user before posting it.

oooh yes, I like that! Feedback the data to be sent to the user and ask for POST confirmation. This "confirmation" page would of course be generated in the same way as the "auto-forwarder" would have been. This could eventually be a preference in Thunderbird: "Display POST confirmation" or somesuch. So.. is there a consensus on the firefox.exe http://localhost:dynamicport/magic.html approach? If so I guess we just need to increase the vote count.

I am novice here... and how can we get this bug fixed? Only by increasing votes? Or write the code ourself? PS: Just for etiquette: my name is Lalov Sergey.

(In reply to comment #35) > This could eventually be a preference in Thunderbird: "Display POST > confirmation" or somesuch. I'd recommend having that on the FF side rather than the TB side. Two reasons behind this: 1. It stops other rogue programs attempting to exploit this (pro-active security) 2. It may allow for cross-program compatibility - i.e. (I know it's not my personal choice, but a lot of people use it) Outlook/OE perhaps on the 'doze side, or whatever else. The approach sounds good though. I wouldn't use a magic HTML page, just a local host and socket, which they can use IPC-style.

Yep, rick, I think that is pretty much what I meant anyway... The "magic.html" was just to indicate a file reference at the end of the socket.. not a physical file. And I had assumed that the confirmation form would be generated from TB but displayed in FF/IE whetever.

(In reply to comment #37) > I'd recommend having that on the FF side rather than the TB side. Two reasons > behind this: > 1. It stops other rogue programs attempting to exploit this (pro-active security) > 2. It may allow for cross-program compatibility - i.e. (I know it's not my > personal choice, but a lot of people use it) Outlook/OE perhaps on the 'doze > side, or whatever else. 1.The problem is only with TB, and TB should handle this, not to shift it to FF. FF doesn't have to care about TB bugs. And IPC method is dangerous too, any other rogue problem can use this. With generating form in TB we can avoid the most of atacks by generating all the script just in a 'onclick' property with 'this' reference to form, so no other form will submit. And with user confirmation we can absolutely protect the user. 2.It provides cross-program compatibility, but from other side, TB can work with any browser. And those, who use Outlook/OE uses IE too, so they work fine with such forms. And when OE user will want to use TB, he will have to install FF too for properly program work. It is uncomfortable. If you want FF to handle this bug, maybe you will like other idea: plugin the FF engine into TB, so the mail will be browsed by FF and POST forms will work fine. Microsoft provides such engine for IE, so one can use it in his own programs.

(In reply to comment #39) > 1.The problem is only with TB, and TB should handle this, not to shift it to > FF. FF doesn't have to care about TB bugs. And IPC method is dangerous too, > any other rogue problem can use this. With generating form in TB we can avoid > the most of atacks by generating all the script just in a 'onclick' property > with 'this' reference to form, so no other form will submit. And with user > confirmation we can absolutely protect the user. Not true. Outlook Express and the like also attempt to enter forms with method=POST. It doesn't work when it sends it to FF either. I'm still not sure what method OE/IE uses though. Regarding FF not having to care about TB bugs - technically, that may be right, but if we want the user base, we have to fix the problems that are causing issues for people. In this case, it's the fact that users can't use HTML forms properly that use POST. They don't care which member of which camp fixes what. A typical example is LiveJournal - it sends out comment fields with a post button, which appear to function perfectly in TB, only to fail in FF as the POSTDATA isn't passed. > 2.It provides cross-program compatibility, but from other side, TB can work > with any browser. And those, who use Outlook/OE uses IE too, so they work fine > with such forms. And when OE user will want to use TB, he will have to install > FF too for properly program work. It is uncomfortable. The problem here is that you can't post forms from TB or anything else into FF at the moment. > If you want FF to handle this bug, maybe you will like other idea: plugin the > FF engine into TB, so the mail will be browsed by FF and POST forms will work > fine. Microsoft provides such engine for IE, so one can use it in his own > programs. We've thought about that. The Gecko engine is already built-in to TB, but apart from the fact it'll hold no relevant cookies etc for the user, it provides much less flexibility - users will generally want to continue browsing after dealing with such a form, and TB is hardly the ideal browsing environment - that's not what it's designed for. FF browses, TB reads mail. I think it should be kept that way, and the interoperability improved. The magic.html file approach is seeming more realistic. Yes, if someone wished to create an attack this way, it's theoretically possible, but if they were so determined, it's not that hard to set one up manually with a HTML file. I'd definately want confirmation though with a detailed dialogue box, showing the site it's being sent to. I'd put checks in though to avoid the likes of PayPal phishing, because users WILL fall into that trap, but I'm not sure how that'd go. Mind you, TB looks like it's getting those identification capabilities already.

Hm. Okay, some other idea: Can whe translate a html mail into the FF by command line parametr? Ofcorse, the mail should be coded before (in Base64, for example). So no file is needed. And ofcorse FF shoul be modifed.

(In reply to comment #41) > Hm. Okay, some other idea: > Can whe translate a html mail into the FF by command line parametr? Ofcorse, > the mail should be coded before (in Base64, for example). So no file is > needed. And ofcorse FF shoul be modifed. Interesting idea - but do command lines have limitations per O/S? My primary concern would be that not all of the form data would be transferred on large forms, hence the idea of a tempfile. Anyone got any ideas of command line lengths?

http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx covers most of the ones you'll come across on Windows, but it basically boils down to the 2048 limit for ShellExecute. Generally speaking, command-lines are very limited in size, and it would be wise to not try and rely on it being long enough (plus it would create some odd bugs if it only failed for some forms).

(In reply to comment #43) > Generally speaking, command-lines are very limited in size, and it would be wise > to not try and rely on it being long enough (plus it would create some odd bugs > if it only failed for some forms). Agreed. Command lines are less than ideal. If we have no direct IPC, we have files as a possibility (with FF confirmation). Have we any other options?

Temporary files and a mini-webserver-thing (comment 29) are the only options I know of which would not require modifications to Firefox to function. I think trying to do the actual post within Thunderbird is just not going to work.

(In reply to comment #45) > Temporary files and a mini-webserver-thing (comment 29) are the only options I > know of which would not require modifications to Firefox to function. I think > trying to do the actual post within Thunderbird is just not going to work. To be honest, I'd be more in favour of that option, as it removes potential file issues. People could still write a program to feed the information in, but if it came to that, they could probably far more easily fashion a direct request. I wouldn't consider security too much of an issue. If this works, it could also pave the way for more TB->Firefox interaction, as well as Sunbird and the like.

Hm. Okay, some other idea: To write a CGI (or something like this). TB translates to a FF a link like firefox.exe "tbroot\someutil.exe -postmailno12345" Then FF executes someutil.exe, which prints out all the needed data, and FF recives it.

(In reply to comment #47) > Hm. Okay, some other idea: > To write a CGI (or something like this). TB translates to a FF a link like > firefox.exe "tbroot\someutil.exe -postmailno12345" > Then FF executes someutil.exe, which prints out all the needed data, and FF > recives it. ..errmm... what is the discussion about? FF already supports http protocol from command-line. just use it (as per my #29 comment) Are there any TB developers out there who want to progress this? I think this is quite an interesting bug to fix, unfortunately I do not have time (or immediate TB experience) to do myself.

(In reply to comment #48) > FF already supports http protocol from command-line. just use it (as per my #29 > comment) The command line may not be suitable, that's the issue. There's limits on the lengths, and could lead to other possible weirdness. Firefox also doesn't support POST from the command line, which led to this initial problem. It's going to be my first real bit of FF/TB hacking, but I'm willing to have a go as soon as I've finished brushing up on my C++. Re the CGI-type program, to be honest, it'd just be an additional step - if we were going to do that, we may as well use a magic html file to do it. We may actually be able to do messily temporarily via a created HTML file with the values pre-filled in, using Javascript to post it automatically, with user confirmation (and values displayed perhaps?), hooking in when there's a POST form available in the current page. (We'd also have to check for multiple forms too.) That would be the easiest way with the magic.html file.

(In reply to comment #49) > (In reply to comment #48) > > FF already supports http protocol from command-line. just use it (as per my #29 > > comment) > > The command line may not be suitable, that's the issue. There's limits on the > lengths, and could lead to other possible weirdness. Firefox also doesn't > support POST from the command line, which led to this initial problem. > > You should read #29 again. There is no problem with commandline length, the idea is to use the url to redirect the request back to TB achieved using the protocol "http://localhost:<dynamic port>/maginc.html" - TB will act as a webserver in this case serving the contents of the "magic.html" or whatever name is given to generate the relevant file, and yes, the generated file would have the values filled in and an "onLoad" bit of javascript used to submit the form.

> You should read #29 again. There is no problem with commandline length, the > idea is to use the url to redirect the request back to TB achieved using the > protocol "http://localhost:<dynamic port>/maginc.html" - TB will act as a > webserver in this case serving the contents of the "magic.html" or whatever name > is given to generate the relevant file, and yes, the generated file would have > the values filled in and an "onLoad" bit of javascript used to submit the form. Sorry, may have gone off on a tangent there. I agreed with that in principle, and it's better than creating tempfiles all over the place. Does this sound viable? Creating the socket shouldn't be a huge problem in theory. So this boils down to a few steps. 1. Scan e-mail when HTML view is enabled for form action="post". 2. Rewrite post URL to indicate an internal chrome link? 3. Use chrome to create magic HTML in memory? 4. Send FF the command line to connect to TB 5. FF loads the link via standard HTTP link 6. FF loads page with pre-filled values, perhaps with a small bit of explanation ("Mozilla Thunderbird is transferring your form values...") or possibly a description of the send form values? 7. FF requests confirmation via onLoad to submit the information 8. FF sends data. This requires no modifications at all to FF, as it's a standard URL. Thoughts?

Yep, spot on I reckon :-) The socket should probably have a one shot only lifetime, so just name the "magic.html" with some generated random number "magic_362983.html" and check against any request made. Maybe a good idea to give the file a meaningful name to make it clear where its come from, say "thunderbird_post_362983.html". Once the data is served then close the socket and free any resource.

So random port and random filename too for added security? Admittedly, it's not hugely great for a security measure, but it'll stop most of the script kiddies. Theoretically, we could do this through pure javascript inside the browser, extension-style, but I'm not certain. I'd personally prefer to keep it in the C++ if possible, but it means going in deeper. Will do some research into the code. The most complicated part is probably creating the port, and even that shouldn't be too difficult.

I have one more (crazy) idea: let's prepare in FF some amount of memory with defined offset (about 100KB), than TB will find firefox.exe process in memory and will write a post data to that container. Then FF will send it after submiting by user.

Processes can't write to each other's memory spaces.

Yup, with good reason - it'd be horribly insecure. Anything could write to that space. 'Fraid it was a little crazy ;) We're continuing discussions offline, and will post more here when I have a proposal.

Haven't had time to work more on this :( Will try to fit some in before new year though...

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

I've been trying to work out the best way to tackle this. So far, my thoughts of the process are as follows: Check for form presence Identify any submit buttons, attach javascript intercept within the mail body view to fire external javascript call When JS call is made: Identify which form the pressed submit button belongs to Create blank HTML from template (add basic head/body attributes etc), add automatic form submission to form body (with confirmation on browser side if set as a pref) Copy form and form contents into HTML file in memory, using hidden values for submission Tag submit button with an ID matching the name (or a random ID if no name specified for submit button), for javascript auto-submit, printed via javascript to avoid conflict with the noscript submit button Add noscript option to submit form, for users with no javascript enabled Open external random port, between set range (prefs?), bound to localhost Display "Submitting form, please wait" on Thunderbird, blocking access to the rest of it, and fire external URL request to http://localhost:randomport/ On retrieval of form via HTTP from the browser, automatically close port and "Submitting form" dialog If no response within a set period set in prefs (30 seconds default), automatically close the port and cancel the dialog box. I'd suggest a countdown in the box. On the browser side: Load HTML form directly from TB socket Auto-submit if javascript enabled (with confirmation if it was set in the TB prefs) "Send e-mail form" button for non-JS enabled browsers ===== Most of this I can do, but I'm working out how to add the JS intercept to the submit buttons, and how to identify the form in question to grab it's info and values. I'll keep researching, but if anyone can help out on that score, I'd appreciate it. Looking at the JS function above, there's a possibility of using onclick='submitform(this)' or something similar to help identify it...

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

Why not to use DDE to transmit information from TB into FF? That would be much more straightforward solution for this problem, than creating some special temporary files, javascripts, etc. One problem is, FF currently doesn't support POSTing by DDE message. But it surely can be done. See #267032.

DDE is also not cross-platform, which poses its own problems. There are, I know, similar systems (in concept if not implementation) on other platforms, but it does make it a trickier solution to use.

Unfortunately I've not had chance to do this myself. I know it's been a while, but work has killed my spare time off. I think the method I suggest would work for definite cross platform, albeit not the cleanest of methods in the world. A temporary HTML file may be better and more secure, although then you'd have to figure out how to automatically delete it once it'd been accessed.

(In reply to comment #15) > With the new RSS reader in Thuderbird this is going to become increasingly > requested. e.g. if you read Slashdot through its RSS feed then when the stories > are displayed in Thunderbird it is not possible to login to your account and > therefore have your default filter settings on comments. For the whole login > process to work inside Thuderbird would require cookies too. > > So the ideal solution would be. Submit a POST request and reload the resulting > page within the same window in Thunderbird. Accept the cookie and remain logged > into slashdot so that when you read the next story it remembers who you are. Bug 318104 has a discussion about that: [RFE] allow feed article browsing inside thunderbird As say here with slashdot, but the problem is still there with flickr rss (missing cookies and login ability in TB) and with other multipage feeds ( http://feeds.feedburner.com/GamasutraFeatureArticles or http://www.escapistmagazine.com/rss.xml ), maybe a best solution to handling post is to have a mini browser inside TB, handling cookies and POST/GET sending with display of the response inside TB.

IS this bug still valid? ThunderBrowse seems to be able to handle POST as of TB3.0.

it is not because a plugin fix the problem than the bug become invalid. it may become "won't fix", but the bug is valid

What I mean is, in TB 2.0 ThunderBrowse wasn't able to handle method="post" because Thunderbird didn't support allowing plugins to do that. Now, in TB 3.0, it does. TB now supports method="post", but it still doesn't support browsing, which is the only sensible way of dealing with method="post" requests, and which is pretty much what bug 318104 asks for, as I'm sure you know ;)

Forms work for me in Thunderbird 3.0.1 without ThunderBrowse for both methods "get" and "post". However, the tag INPUT type="sumbit" does not work. Only the tag BUTTON type="submit" works. I suspect that means this bug should be closed, and another one opened for the INPUT tag problem. Or maybe this bug was about the INPUT tag all along? By the way, I can think of perfectly sensible uses for forms that do not require browsing. For example, the PHP script I used for testing replied by e-mail.