Last Comment Bug 533545 - Form submission from HTML mail is completely broken (action = get)
: Form submission from HTML mail is completely broken (action = get)
Status: RESOLVED WONTFIX
[GS]
: regression, testcase
Product: Thunderbird
Classification: Client Software
Component: Mail Window Front End (show other bugs)
: Trunk
: All All
: -- major with 13 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
https://getsatisfaction.com/mozilla_m...
: 542325 580918 633098 647643 669818 670075 (view as bug list)
Depends on: 782580
Blocks: 423488
  Show dependency treegraph
 
Reported: 2009-12-08 13:18 PST by David F. Skoll
Modified: 2013-04-26 12:39 PDT (History)
21 users (show)
standard8: wanted‑thunderbird+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
wanted


Attachments
Test email demonstrating broken form submission (298 bytes, message/rfc822)
2010-01-21 06:24 PST, David F. Skoll
no flags Details
contentAreaClick.js with changes affecting HTML form submission (7.11 KB, application/javascript)
2010-08-03 09:47 PDT, Kay Wrobel
no flags Details
Fix contentAreaClick function to not open URLs for elements inside a form. (995 bytes, patch)
2010-08-04 14:22 PDT, Kay Wrobel
no flags Details | Diff | Splinter Review
Fix contentAreaClick function to not open URLs for elements inside a form (1.39 KB, patch)
2010-09-28 09:15 PDT, Kay Wrobel
standard8: review-
Details | Diff | Splinter Review

Description David F. Skoll 2009-12-08 13:18:53 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

Consider the following message:

Subject: Form test
From: <dfs@roaringpenguin.com>
To: <dfs@roaringpenguin.com>
Content-Type: text/html
MIME-Version: 1.0

<html>
<head>
</head>
<body>
<form method="GET" action="http://127.0.0.1/get-test">
Who are you?  <input type="text" name="name">
<input type="submit">
</form>
</body>
</html>

In Thunderbird 2, submitting the form does a GET to a URL like this:

http://127.0.0.1/get-test?name=david

In Thunderbird 3, the form entry data is COMPLETELY ignored and you get:

http://127.0.0.1/get-test


Reproducible: Always

Steps to Reproduce:
1. Send the message above
2. Enter your name in Thunderbird 2.  It works.
3. Enter your name in Thunderbird 3.  It fails.
Comment 1 syd 2009-12-15 16:29:46 PST
It's a problem on MacOS platform as well
Comment 2 David F. Skoll 2010-01-20 13:33:30 PST
Any progress on this bug?

Regards,

David.
Comment 3 Ludovic Hirlimann [:Usul] 2010-01-21 05:42:23 PST
Can you attach an email reproducing the issue, that would give us a testcase ?
Comment 4 David F. Skoll 2010-01-21 06:16:43 PST
I already posted a test case.  See Comment https://bugzilla.mozilla.org/show_bug.cgi?id=533545#c0
Comment 5 Ludovic Hirlimann [:Usul] 2010-01-21 06:17:49 PST
(In reply to comment #4)
> I already posted a test case.  See Comment
> https://bugzilla.mozilla.org/show_bug.cgi?id=533545#c0

I'm asking for an attached file that can be easily downloaded.
Comment 6 David F. Skoll 2010-01-21 06:24:01 PST
(In reply to comment #5)

> I'm asking for an attached file that can be easily downloaded.

OMG, you're kidding.  You can't take a plain MIME message?

*sigh*  OK, I will attach.
Comment 7 David F. Skoll 2010-01-21 06:24:59 PST
Created attachment 422737 [details]
Test email demonstrating broken form submission
Comment 8 Ludovic Hirlimann [:Usul] 2010-01-21 06:32:39 PST
Standard8 was this done by design ?
Comment 9 Kazuya Sakamoto 2010-02-04 22:27:23 PST
I saw this on Windows XP now.
When I click the text field in the form tag with GET method,Thunderbird open the new window with the value of action property of the form as the URL.
Comment 10 richs 2010-02-11 08:45:45 PST
Confirming this in Thunderbird 3.0.1 on both Mac OS X and Windows. Works in Thunderbird 2.x.

Clicking on an "input" form element (checboxes, text, etc) instantly submits the form (get or post) without any values.  Even clicking on a "submit" element in a form with hidden inputs does not submit their values.

All forms requiring input are broken in Thunderbird 3 because of this.
Comment 11 David F. Skoll 2010-03-22 11:36:01 PDT
Any progress on this bug?
Comment 12 Kazuya Sakamoto 2010-03-22 17:25:50 PDT
no progress on 3.0.3
Comment 13 Evan Stratford 2010-03-24 21:37:41 PDT
Confirming both the initial report and @richs' comment about behaviour where clicking on input elements instantly submits the form.
Comment 14 Ludovic Hirlimann [:Usul] 2010-03-29 06:11:35 PDT
Would be nice to know when this regressed (see http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ on how to achieve that).
Comment 15 Mark Banner (:standard8) 2010-03-29 06:28:03 PDT
(In reply to comment #14)
> Would be nice to know when this regressed (see
> http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/
> on how to achieve that).

I can be pretty sure its a regression from bug 516776. I've just not had time to get back and look at this bug yet.
Comment 16 Kay Wrobel 2010-04-08 09:31:44 PDT
I am using Ubuntu 9.10 64bit and Thunderbird (Shredder) 3.05pre from the PPAs. This is bug happens here as well. We're using HTML forms within our company quite a bit as a simple way to provide feedback. We're transitioning many users to Thunderbird and we have loaded version 3 of Thunderbird. Needless to say, we're unhappy.

Will this be taken care of soon?
Comment 17 Mark Banner (:standard8) 2010-04-08 13:32:15 PDT
I'm pretty sure this is an issue with the form handling bit of code here:

http://hg.mozilla.org/comm-central/annotate/359fc1dbd00e/mail/base/content/contentAreaClick.js#l63

However, doing a quick comparison of code between TB, FF & SM I just can't see how to correct it.

Due to other big issues I've got on my plate, I'm not going to be able to look at this for the next week or two. So if anyone else has time, the above is where to start looking.

If not, I'll try and make time before the 3.0.5 release.
Comment 18 David F. Skoll 2010-05-29 06:20:45 PDT
This is *still* broken in 3.1 RC 1.  When I click on a Submit button in a form, nothing happens.  The error console says:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188"  data: no]

TB is unusable for me until this is fixed. :(
Comment 19 Ludovic Hirlimann [:Usul] 2010-07-26 04:36:23 PDT
*** Bug 580918 has been marked as a duplicate of this bug. ***
Comment 20 Kay Wrobel 2010-07-27 06:32:42 PDT
Ok, I'm know how to code, but I have .NET and VB background. I have seen JavaScript and would be able to read and possibly modify the code Mark Banner refers to. But I have no idea how to use the revision system Mercurial, nor how to test any modifications.

What I would like to compare is the source for contentAreaClick.js in Thunderbird 2.0.0.24 (which is what I'm using right now, working) and the first version in Thunderbird 3 in which this was already broken. Who can point me to the source? Or is it already on that page Mark referenced?

Anybody please.
Comment 21 Ludovic Hirlimann [:Usul] 2010-07-27 06:46:13 PDT
Reading https://developer.mozilla.org/en/comm-central is a good starting point. #maildev on irc.mozilla.org is the good place to ask technical questions.
Comment 22 Kay Wrobel 2010-07-27 06:58:03 PDT
Thanks Ludovic. That'll give me something to read.
Comment 23 Kay Wrobel 2010-08-02 12:35:42 PDT
Hi all.

Sorry that it took me a while to reply. Here's what I found. I took the release code of TB 3.0 and compiled it as is. The bug happens as described above. I then downloaded TB 2.0.0.24 release code and copied the file mail/base/content/contentAreaClick.js AS IS to the equivalent directory of TB 3.0 and recompiled. I am surprised but the code actually works. I can report here and now that I could fill out a form field and hit the Submit button successfully. My test form looks like this:

<form id="form2" method="get" action="formtest.php">
Please enter some date:
<input id="best_date" name="best_date" type="text" />
<input type="submit" value="Submit" />
</form>

The URL opened http://localhost/formtest.php?best_date=2%2F22%2F2010 after I entered 2/22/2010 in the field.

I know this is definitely not recommended, but I was just curious if the original code would work at all with the new TB3 code. I saw that the new contentAreaClick.js looks considerably different and I tried to spot where things may break. But without proper debugging, I can't tell for certain. I have a strong feeling that the function "contentAreaClick(aEvent)" is broken.

I would really love to debug this code. Seems to be JavaScript, and I installed Venkman for debugging JavaScript. But I don't find a way to actually link the debugger to that particular file. Any help (hints, links) is much appreciated.

I will also try to download the current release code for TB3 and see if the old contentAreaClick.js plays nice with it.
Comment 24 Kay Wrobel 2010-08-02 13:50:26 PDT
Ok, quick update: TB3.1.1 release code compiled, still same bug (as expected). Replaced contentAreaClick.js (same location as mention above) with version from 2.0.0.24 release code, recompiled and works as described above.

Just thought I'd let you know.
Comment 25 Mark Banner (:standard8) 2010-08-02 14:06:44 PDT
(In reply to comment #23)
> I know this is definitely not recommended, but I was just curious if the
> original code would work at all with the new TB3 code. I saw that the new
> contentAreaClick.js looks considerably different and I tried to spot where
> things may break. But without proper debugging, I can't tell for certain. I
> have a strong feeling that the function "contentAreaClick(aEvent)" is broken.

The main thing this would likely break is content tabs - used for the What's new page, about pages and also for extensions. Hence using this workaround in production is definitely not recommended.

> I will also try to download the current release code for TB3 and see if the old
> contentAreaClick.js plays nice with it.

My main thought is that this change in hRefForClickEvent:

-    else if (target instanceof HTMLInputElement)
+    else if (!aDontCheckInputElement && target instanceof HTMLInputElement)

(from http://hg.mozilla.org/comm-central/rev/2d246c8d3fa4)

wants reverting.

I'm not totally sure why I did that change in the first place, though I'm also not sure it will actually fix it.

Can you give that a try?

It would probably also be useful to log what hRefForClickEvent is returning and what contentAreaClick is doing with it.
Comment 26 Kay Wrobel 2010-08-02 14:31:01 PDT
Mark,

I made the change in 3.1.1 release code as suggested, but the problem still persists. You click the text field and the browser opens immediately. I also noticed that when I turn on the Error Console in TB, when I use the 2.0.0.24 version of the script in 3.1.1, I get an uncaught exception as I click on the input field:

Error: uncaught exception: Load of http://localhost/formtest.php denied.

So it looks almost as if the original code also has some URL opening in place, but that opening the URL is rejected by some code. This would make sense. I think when a user clicks on any form input element (including the submit button, the script shouldn't even try to "open" the link but simply ignore the click. But when the user clicks on the Submit button, it should process the form as designed.

So I'm not sure right now what should be happening. I think that the script should actually fail to open the link? Mark, you know the code much better than I do.
Comment 27 Kay Wrobel 2010-08-03 08:51:52 PDT
Ok, I feel completely lost here. I just eliminated all functions defined in contentAreaClick.js with the exception of contentAreaClick(event), which is referenced in two .xul files. Basically, the file looks like this now:

  function contentAreaClick(event) 
  {
    return true;
  }

That's pretty much it. I compile 3.1.1, open my email with HTML form, and even a link to some web site, and both link and form function properly and open up in my browser, including proper URL encoding for the GET form method.

Somebody please enlighten me what this script file is actually supposed to do?

Thanks.
Comment 28 Kay Wrobel 2010-08-03 09:47:52 PDT
Created attachment 462418 [details]
contentAreaClick.js with changes affecting HTML form submission

I've done further testing with the release code of 3.1.1 and contentAreaClick.js. I am proposing to change the contentAreaClick function to test whether the clicked target is a form field and the return true. This is inserted towards the middle of the function before we decide to open everything in the external browser. I have tested this on my Ubuntu 9.10 (64-bit) distro and works nicely.

Please advise if anything else might have broken this way. Also, if others agree, how can we turn this into a patch?
Comment 29 Ludovic Hirlimann [:Usul] 2010-08-04 09:05:46 PDT
(In reply to comment #28)

> Please advise if anything else might have broken this way. Also, if others
> agree, how can we turn this into a patch?

https://developer.mozilla.org/en/comm-central#Requirements
Comment 30 Kay Wrobel 2010-08-04 09:32:34 PDT
Thanks, Ludovic. As I mentioned before, I'm not familiar at all with Mozilla's development rules, and there's just so much information on the web site, I can't find my way through, honestly.

But, I will start by actually preparing a patch and attach it to this bug for review. Is that how I should proceed from here? And who would take over the review?
Comment 31 Ludovic Hirlimann [:Usul] 2010-08-04 09:42:44 PDT
That's the idea. set the review flag to ? and ask :standard8 that should do it.
Comment 32 Kay Wrobel 2010-08-04 09:49:36 PDT
Great thanks. So what instructions should I follow for creating the patch? After all, I only inserted 5 lines or so + comments. Where should I start? Can I simply use the diff statement and run that against 3.1.1 release version and my changed version and output that to a new file and that's the patch?
Comment 33 Ludovic Hirlimann [:Usul] 2010-08-04 09:59:22 PDT
(In reply to comment #32)
> Great thanks. So what instructions should I follow for creating the patch?
> After all, I only inserted 5 lines or so + comments. Where should I start? Can
> I simply use the diff statement and run that against 3.1.1 release version and
> my changed version and output that to a new file and that's the patch?

No :-( You'll need to set up a build environment and make a patch using hg diff (see https://developer.mozilla.org/en/Simple_Thunderbird_build on how to do that). Sorry there plenty of things you'll need to do for that ...
Comment 34 Philip Chee 2010-08-04 10:35:25 PDT
I think you probably want something like:

// Returns true if target is a form control (except text boxes and images).
if (target instanceof HTMLInputElement && !aNode.mozIsTextField(false) && aNode.type != "image")
  return true;
Comment 35 Kay Wrobel 2010-08-04 14:22:58 PDT
Created attachment 462918 [details] [diff] [review]
Fix contentAreaClick function to not open URLs for elements inside a form.
Comment 36 Mark Banner (:standard8) 2010-08-13 07:30:55 PDT
I've taken a look at this, whilst it is better functionality wise than what we have now, my concern is that we'd be loading the form within Thunderbird. I need to think about if that has other negative aspects or potential issues.
Comment 37 Kay Wrobel 2010-08-13 07:54:18 PDT
Sure. All I can think of is that it "might" be considered a security risk for some, and a valuable feature for others. Let me just say that other email clients work perfectly with regards to HTML Forms in emails. We have users running the latest Apple Mail, Microsoft Outlook, Windows Mail and Outlook Express. Some also have Eudora still on their computers. All of these programs have no problem submitting the embedded HTML Form.

So, I'm hoping that you will conclude with us who are really looking to get this fixed that we should roll out a patch. My two cents on this...
Comment 38 Kay Wrobel 2010-09-28 09:15:18 PDT
Created attachment 479074 [details] [diff] [review]
Fix contentAreaClick function to not open URLs for elements inside a form

Changed var target assignment to be same as in hRefForClickEvent. Changed open braces to be on same line as IF statement.
Comment 39 Kay Wrobel 2010-09-28 09:18:44 PDT
I have updated the patch to reflect the original assign statement for the target variable, which was dependent on isKeyCommand variable. I recompiled the code and Form submission still works. Doesn't seem to have broken anything yet.

No ETA yet on a review...
Comment 40 Mark Banner (:standard8) 2010-10-19 07:15:58 PDT
*** Bug 542325 has been marked as a duplicate of this bug. ***
Comment 41 Kay Wrobel 2010-10-29 07:42:48 PDT
I just like to report that ever since I uploaded the proposed patch, which was around 3.1.3, I have been recompiling 3.1.4, 3.1.5 and now 3.1.6 release tarballs with my patch applied. I can safely say it's still working with no issues that I can think of.

The review is still being held back, unfortunately.
Comment 42 Guillermo López :willyaranda (probably SLOW response) 2010-10-29 12:44:46 PDT
Ludovic, ping on this
Comment 43 Mark Banner (:standard8) 2010-10-29 14:17:49 PDT
Sorry, for not getting to this earlier. I was hoping to look at it this week, but half the week got taken out with a security release. I'm still not convinced this patch does the right/expected thing, but I'm going to be getting one of our servers to create some builds over the weekend that I can try out in different places.
Comment 44 Mark Banner (:standard8) 2010-11-05 12:23:46 PDT
I've just checked this patch out on a fresh windows user account with a form in an email. Firefox was run up and set as default browser, then Thunderbird installed and set up.

Here's the form extract from the email:

    <form method="GET" action="http://127.0.0.1/get-test">
      Who are you? <input name="name" type="text">
      <input type="submit"><br>
      <br>
      This is a test form<br>
    </form>

When I tried to load that, it replaced the message body with an error that it couldn't load the page (expected). It did not replace/clear out the message header. Therefore I think we need to examine a better way/hook for either replacing the whole message body and header, or for redirecting the submission to the default browser.
Comment 45 Kay Wrobel 2010-11-05 12:31:26 PDT
Did you test with the HG code or with the latest release archive? I notices that it never worked for me (under Linux) with the latest HG code, but the latest release tarball always worked (proven over three minor releases)... Anyway, there goes wishful thunking we'll get this into release any time soon. I bet we'll still be talking about this next year... (shaking my head in frustration).

I have to add, though, that I have not been able to test this against Windows since I don't have the environment to do it. So there might be some architectural difference.
Comment 46 Mark Banner (:standard8) 2010-11-05 12:42:06 PDT
I tested with the latest 3.1.7pre code as of 01/11/10. So there shouldn't be any significant difference there.

Interesting that you imply the latest trunk is different, I've got Linux builds as well, so I'll try and give them a go soon.
Comment 47 Mark Banner (:standard8) 2011-01-04 14:05:56 PST
Comment on attachment 479074 [details] [diff] [review]
Fix contentAreaClick function to not open URLs for elements inside a form

Ok, so it appears the test case I was using before was slightly bogus and the patch does do what you say it does.

However, there's something I'm concerned about going on in the background, namely this: the patch causes two http gets for the form, one from Thunderbird and one from Firefox.

What I don't understand is why. From brief debug, what I can tell happens with the patch is this:

1) User clicks the submit button
2) Thunderbird's contentAreaClick function decides not to handle the patch, so it goes into the default processing code
3) This appears to end up going through the uriloader or something, and ending up in our nsIContentHandler implementation in mailContentHandler.js
4) mailContentHandler.js redirects it to the external browser as it is an http source.
5) The browser loads the fully submitted form URL and displays the result.

So the route from step 2 to step 3 is where the extra request happens from within Thunderbird.

What I don't yet understand is why it goes through that route, or if there is a way we can hook into it to stop it requesting from within Thunderbird.

I'm cancelling the review for now and going to assign the bug to me for further investigation. I'm not plussing it at the moment because of the double-request issue, and I'd like to make sure we exhaust the possibilities before we consider this.
Comment 48 Kay Wrobel 2011-01-04 14:25:32 PST
Mark: If there's anyway I can help, let me know.
Comment 49 Boris Zbarsky [:bz] (still a bit busy) 2011-01-04 20:13:28 PST
> What I don't yet understand is why it goes through that route

Because nothing tells it not to.  The default action of a submit button is to submit the form.

> or if there is a way we can hook into it to stop it requesting from within
> Thunderbird.

You could preventDefault the click.  You could also make your nsIURIContentListener's onStartURIOpen return false, but all you know there is the URI.  And if you do that, then of course your nsIContentHandler won't be triggered.  nsIContentHandler is meant to _handle_ content.  It's called once we have a respose from the server.
Comment 50 Boris Zbarsky [:bz] (still a bit busy) 2011-01-04 20:13:42 PST
Er, "a response from the server".  ;)
Comment 51 Kay Wrobel 2011-03-23 06:08:47 PDT
Will there ever be any movement on this topic?
Comment 52 stsivaraj 2011-07-05 06:45:00 PDT
 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12)

Gecko/20101027 Fedora/3.6.12-1.fc13 Firefox/3.6.12

Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12)

Gecko/20101027


Hi All,

I am having Fedora/3.1.6-1.fc13 Thunderbird/3.1.6. A mail has html content and

on clicking radio button(Checkbox,textbox...) the form gets submit. How to

control the submitting the form while clicking the radio button,text box, etc.?


Focus is, the form submit is controlled by submit button rather than when i

click the form controls


If i use Thunderbird3.1.6 - Problem is When i click radio button form will

submit

If i use Thunderbird2.0.0 - Problem is Form submit not work.

This reply was created from a merged topic originally titled
Email Form not submit.
Comment 53 Ludovic Hirlimann [:Usul] 2011-07-07 00:22:56 PDT
*** Bug 669818 has been marked as a duplicate of this bug. ***
Comment 54 Ludovic Hirlimann [:Usul] 2011-07-08 08:30:08 PDT
*** Bug 670075 has been marked as a duplicate of this bug. ***
Comment 55 Kay Wrobel 2011-07-08 08:48:12 PDT
To the maintainer of this bug: Problem still exists in v5.0 of Thunderbird. And I still managed to take the 5.0 release source code and apply the small changes in contentAreaClick.js as proposed above. And that solution still works for me.

Put your security concerns aside already and fix this issue, please. I am VERY inclined right now to switch to Evolution mail...
Comment 56 Kay Wrobel 2011-07-08 08:51:00 PDT
P.S.: Look at the AGE of this bug. I wouldn't call this a working open-source project where people actively contribute, but then get stuck aside in a drawer where bugs get forgotten. This is a working solution.
Comment 57 Ludovic Hirlimann [:Usul] 2011-07-13 05:18:26 PDT
*** Bug 633098 has been marked as a duplicate of this bug. ***
Comment 58 stsivaraj 2011-07-14 00:20:45 PDT
(In reply to comment #55)
> To the maintainer of this bug: Problem still exists in v5.0 of Thunderbird.
> And I still managed to take the 5.0 release source code and apply the small
> changes in contentAreaClick.js as proposed above. And that solution still
> works for me.
> 
> Put your security concerns aside already and fix this issue, please. I am
> VERY inclined right now to switch to Evolution mail...

Please, can you specify the exact path location for "contentAreaClick.js". My box is linux fedora 13. 

And specify the "which content i want to edit"
Comment 59 stsivaraj 2011-07-14 04:17:08 PDT
Also how can i get 5.0 release source code ?
Comment 60 Ludovic Hirlimann [:Usul] 2011-07-14 04:31:43 PDT
(In reply to comment #59)
> Also how can i get 5.0 release source code ?

https://developer.mozilla.org/En/Simple_Thunderbird_build(In reply to comment #58)

> (In reply to comment #55)
> Please, can you specify the exact path location for "contentAreaClick.js".
> My box is linux fedora 13. 

https://mxr.mozilla.org/comm-central/search?find=%2F&string=contentAreaClick.js
Comment 61 Kay Wrobel 2011-07-14 06:53:50 PDT
(In reply to comment #59)
> Also how can i get 5.0 release source code ?

I FTP'd into ftp.mozilla.org and changed to/pub/mozilla.org/thunderbird/releases/5.0/source (latest/source or latest-5.0/source also works). Then I unpacked the bz2-compressed TAR archive into some directory, let's call it $HOME/src. The TAR will create a directory called 'thunderbird'.

(In reply to comment #58)
> (In reply to comment #55)
> > To the maintainer of this bug: Problem still exists in v5.0 of Thunderbird.
> > And I still managed to take the 5.0 release source code and apply the small
> > changes in contentAreaClick.js as proposed above. And that solution still
> > works for me.
> > 
> > Put your security concerns aside already and fix this issue, please. I am
> > VERY inclined right now to switch to Evolution mail...
> 
> Please, can you specify the exact path location for "contentAreaClick.js".
> My box is linux fedora 13. 
> 
> And specify the "which content i want to edit"

I then modified the file $HOME/src/thunderbird/mail-miramar/mail/base/content/contentAreaClick.js file. Check out the patch file I submitted to this bug (see at top of this page). Here's a quick link: https://bugzilla.mozilla.org/attachment.cgi?id=479074
That's what I have added to the file.

I then created the required .mozconfig file under $HOME/src/thunderbird/mail-miramar that looks like this:

mk_add_options MOZ_CO_PROJECT=mail
mk_add_options MOZ_OBJDIR=/opt/thunderbird-5.0_custom
mk_add_options MOZ_MAKE_FLAGS="-j4"
ac_add_options --enable-application=mail
ac_add_options --disable-libjpeg-turbo

I am now on Debian 6 (Squeeze) and had to disable the turbo jpeg to make it work on Debian. Then run 'sudo make -f client.mk' and watch the show. It creates a path under /opt that I am using. So in this case, my executable is found in /opt/thunderbird-5.0_custom/mozilla/dist/bin. Make sure you have all the prerequisites installed. There's a good read on Mozilla's web site here:

https://developer.mozilla.org/En/Simple_Thunderbird_build

With these steps, I created a Thunderbird version that allows me to actually click inside form fields or on Submit buttons without Thunderbird capturing the click-event and then doing it's own parsing of where the URL is. But instead, this change does NOT capture the click and let's the underlying HTML logic do it's form submit (GET or POST). That's what this bug is all about and that's how all other mail clients I have tested so far (Outlook Express, Outlook, MS Mail, Eudora 5&7, Evolution mail to name a few) including Thunderbird up to 2.x have handled worked. Thunderbird 3.0 introduced this issue and it has never been fixed even though this patch seem to do its job.
Comment 62 Ludovic Hirlimann [:Usul] 2011-07-14 07:02:06 PDT
Comment on attachment 479074 [details] [diff] [review]
Fix contentAreaClick function to not open URLs for elements inside a form

setting a reviewer if we want to get the pacth in :-)
Comment 63 Kay Wrobel 2011-07-14 07:07:41 PDT
(In reply to comment #62)
> Comment on attachment 479074 [details] [diff] [review] [review]
> Fix contentAreaClick function to not open URLs for elements inside a form
> 
> setting a reviewer if we want to get the pacth in :-)

I was previously assigned to this bug (check out the history). But then standard8 got involved and had concerns and eventually had removed me and assigned himself. So I'm not sure if I can add more to this. I feel like other people may have to step up to move this bug forward.
Comment 64 jiunarayan 2011-07-16 06:26:08 PDT
Is there a location to get the compiled things or patch or something that will make the "Form click content function" in TB3.1.11
Comment 65 wcecchin 2011-09-20 09:30:20 PDT
Until now (20th September 2011) the problem is not yet fixed. on Thunderbird version 6.0.2.

In addition the contentAreaClick.js file now is in the global
omni.jar file, with that path:
\chrome\comm\content\communicator\contentAreaClick.js

In addition the file omni.jar is corrupted in Thunderbid 6.0.2, Italian version.
I wrote some code to patch the bug with an omni.jar substitution.

Because the omni.jar file on italian version is corrupted, that code substitute omni.jar file.

Here there is the program I wrote to fix the bug (for italian language people):
http://www.droplet.it/patch_thunderbird/patch-thunderbird-002.exe
http://www.droplet.it/patch_thunderbird/patch-thunderbird-002.jar

Finally, if you are located in another country you can change the code as
you need (basically you have to generate your own omni.jar in /patch/lib folder):
http://www.droplet.it/patch_thunderbird/patch_thunderbird_002_src.zip

The use of my code is on your own responsability:
http://www.gnu.org/licenses/gpl-3.0.html
Comment 66 wcecchin 2011-09-20 09:39:39 PDT
As in my previous reply, the file now is locate in omni.jar archive.
Inside the archive the file had this path:
/chrome/comm/content/communicator/contentAreaClick.js

regards

(In reply to stsivaraj from comment #58)
> (In reply to comment #55)
> > To the maintainer of this bug: Problem still exists in v5.0 of Thunderbird.
> > And I still managed to take the 5.0 release source code and apply the small
> > changes in contentAreaClick.js as proposed above. And that solution still
> > works for me.
> > 
> > Put your security concerns aside already and fix this issue, please. I am
> > VERY inclined right now to switch to Evolution mail...
> 
> Please, can you specify the exact path location for "contentAreaClick.js".
> My box is linux fedora 13. 
> 
> And specify the "which content i want to edit"
Comment 67 Mark Banner (:standard8) 2011-09-26 05:38:58 PDT
*** Bug 647643 has been marked as a duplicate of this bug. ***
Comment 68 Kay Wrobel 2011-11-22 07:38:59 PST
It's November 2011 and Thunderbird is now on release version 8.0. This bug is STILL in 8.0. How very frustrating. I just downloaded the source for release 8.0 and applied the simple changes to the file that I suggest has issues. Compiled fine and my patch still works as proposed. When can we finally get a review? Please? This is not a good example for open-source development and having a bug span over six (6) major release versions is rather ridiculous.
Comment 69 Mark Banner (:standard8) 2012-02-24 02:11:26 PST
Comment on attachment 479074 [details] [diff] [review]
Fix contentAreaClick function to not open URLs for elements inside a form

Sorry for the big delay in this. As I've alluded to before, I'm not happy with the security aspects of just fixing form submission to work.

Therefore I've set up a thread on the mozilla.dev.security newsgroup to consider possible routes to be able to move this forward in some way:

http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/72f921bb9c5debfa#
Comment 70 daniel@daniel-ritter.de 2012-04-02 10:36:27 PDT
OK, I discovered this Bug today. I can see that it has some kind of history.
I am on Thunderbird 11.0 from the Ubuntu-Repository.

Bug is still there, my Form submits instantly when i click into an <INPUT> field.

Would be great to see a fix...
Comment 71 Brad Hubbard 2012-08-14 01:59:12 PDT
I've got users continuing to report this in version 14 on Win7.

Thunderbird is the only client we've discovered with issues around form submission via email. Even multiple mobile phone clients (provided they support HTML email) have no issue here.

Can you explain the security issues if they're a total show-stopper?
Comment 72 Kay Wrobel 2012-08-14 06:43:20 PDT
So, let's see. It's 8/14/2012 now, Thunderbird is on version 14. The bug was opened Dec. 2009 starting with version 3. I am still assigned to the bug, which is fine by me. I have not tested the small changes I've made with any recent version. I will still contribute whatever I can, but unless reviewers take some time to concentrate on this bug and flesh out their security concerns, I don't see this going anywhere.

I've personally switched to KDE 4.8 which uses the Personal Information Manager (PIM), Akonadi under the hood and KMail as email client. Works good for me...
Comment 73 Vincent (caméléon) 2012-08-14 07:10:26 PDT
Why not fixing this bug and just add a warning advertising the user of the risk of submitting sensitive information through email form? Corporate user would be happy with that I guess, and the risk is not so high (out of subject: I receive scam message in plain text very often which ask me my username and password and Thunderbird scam filter is not able to protect me against this threat...).
Comment 74 tyomitch 2013-03-08 00:53:22 PST
Can't believe three years have passed, and this bug is still there...
Comment 75 Kay Wrobel 2013-03-08 06:25:36 PST
I have given up on the team. If they were serious about their review process, they would have given my patch a serious chance. At this point, all I can say is so be it.
Comment 76 Mark Banner (:standard8) 2013-03-08 06:43:02 PST
Sorry, but I thought I had responded to this since comment 69.

In comment 69, I mentioned that we were discussing this publicly on the security lists. That discussion backed up my already significant concerns that there were security issues with allowing HTML forms in emails. No-one has come up with a reasonable argument in favour of support forms despite the possible risks.

Therefore, as module owner, I am going to say that we are not going to fix this bug on security grounds - we cannot put users at further risk of phishing. Bug 782580 has already been raised to remove form elements from emails when they are displayed (in whichever format of display).

I can appreciate that this may be disappointing for Enterprises, however, we need to consider all users and their security. Additionally for enterprises there are other ways of creating surveys that use full browser protection, something that can't be handled easily within emails.
Comment 77 Kay Wrobel 2013-03-08 06:52:52 PST
And with that, I say: bye-bye Thunderbird. Sorry, but that's just unacceptable. Instead of finding a secure working solution, you just give up.

I'm out...
Comment 78 Brad Hubbard 2013-03-08 11:10:04 PST
Also disappointed to hear that is the final conclusion. I have a service that uses inline forms as a way to keep users from having to open a browser, log in, etc. I'll just have to begin training my users not to use Thunderbird.
Comment 79 syd 2013-03-08 13:32:44 PST
Mark - I'm sorry but your rationale for not approving this fix is totally illogical:
- If your reason is that it is to protect users from phishing scams, then TB should disable ALL hyperlinks in email. There is no evidence nor fact that having a form submission will increase the risk of users falling for phishing scams
- The most obvious solution is to have a option to enable forms which is turned off by default, but for enterprise or other users who wish to use forms, let the user decide to turn it on, and accept the consequences
- At the very least, allow a 3rd party to develop a plugin that allowed form submission

I hope as the module owner you will reconsider this decision as your supporting rationale does not support your conclusion.
Comment 80 daniel@daniel-ritter.de 2013-03-10 09:53:36 PDT
It's a pitty to read this. For me this is broken functionality. All other E-Mail clients allow it. Thunderbird even shows the forms, user think it works. Not all developers test their mails in all e-mail clients. This behaviour blocks many legit applications. 

I would like to add my own voice to the others above.
Please fix this or restrict it to a user setting, or ask users if they REALLY want o to submit this form.
Comment 81 tyomitch 2013-03-10 13:32:04 PDT
(In reply to Mark Banner (:standard8) from comment #76)

> In comment 69, I mentioned that we were discussing this publicly on the
> security lists. That discussion backed up my already significant concerns
> that there were security issues with allowing HTML forms in emails. No-one
> has come up with a reasonable argument in favour of support forms despite
> the possible risks.

Wait, what precisely are the risks?

On the mailing list, you wrote: "With no indication of where the submission is going to, the user could be at serious risk." How is this any different from web forms on web pages?
Comment 82 pi 2013-04-26 12:13:07 PDT
Who's we?  You and the people posting how **** off they are at this?  Sounds like it's been a one way conversation for about three years now. 

Geez...it worked on Thunderbird 2...and every other email client I've ever used.  

The rational is also lame (anyone reading this, even those agreeing with the security argument) can clearly see that.  The broken form submission is an unintended consequence of the tabbed feature in 3.0...since form submission worked in 2.0.  "now that I think about it, we shouldn't fix it because it's a security issue" is really pathetic.  If you don't want to fix it, don't fix it...but please stop with the excuses.  

Regarding the security issue, if it is an issue, a user should have the ability to turn it on / off (the same way you can turn on/off auto downloading of images for trusted users).  But I guess the problem there might be more work on the module.  I don't know how this works, but if you've got better things to do, pass off the development to someone who actually has the time to implement something better than what's available now.  And by the way, this has been an issue for 3 years now....it's clear you have neither the time or inclination to care about usability.  At the bare minimum the form should be completely disabled.  

Now I have to either downgrade to 2.0 or use another email client. 

UNRESOLVED WONTFIX.  RESOLVED GIVE IT TO SOMEONE ELSE TO FIX.
Comment 83 Kay Wrobel 2013-04-26 12:39:22 PDT
As the person who originally suggested a way to fix this, I found the arrogance of the module maintainer quite startling. It flies in the face of a community process where, clearly, there is a community that is interested and willing to fix this bug out of a need, particularly when it's a feature that so many other email clients support.
Simply shrugging it off after so many years of the bug being open, or better yet, giving up on the topic under the pretense of security without even considering an option or even fostering a discussion about this, that just ****** me off personally. I despise what has become of this "open-source" project. It clearly is not as democratic and open as one might expect. Anyway, I'm not going to touch this topic or code anymore. They have a suggested fix, they can read and program, I'm not going to touch this code anymore.

pi: btw, someone else might just run into the same problem since an alternate solution would still have to be reviewed by the same people who think that form submission from within an email is a security risk and not worth their time. At this point, I don't see this ever getting fixed... It's simply off the radar now.

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