Closed Bug 533545 Opened 15 years ago Closed 11 years ago

Form submission from HTML mail is completely broken (action = get)

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(thunderbird3.1 wanted)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
thunderbird3.1 --- wanted

People

(Reporter: dfs, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: regression, testcase, Whiteboard: [GS])

Attachments

(2 files, 2 obsolete files)

Test email demonstrating broken form submission
298 bytes, message/rfc822
Details
Fix contentAreaClick function to not open URLs for elements inside a form
1.39 KB, patch
standard8
: review-
Details | Diff | Splinter Review 
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.
Version: unspecified → 3.0
Component: General → Mail Window Front End
Keywords: regression
QA Contact: general → front-end
It's a problem on MacOS platform as well
Any progress on this bug?

Regards,

David.
Can you attach an email reproducing the issue, that would give us a testcase ?
OS: Linux → All
Hardware: x86 → All
I already posted a test case.  See Comment https://bugzilla.mozilla.org/show_bug.cgi?id=533545#c0
(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.
(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.
Keywords: testcase
Standard8 was this done by design ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Form submission from HTML mail is completely broken. → Form submission from HTML mail is completely broken (action = get)
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.
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.
Any progress on this bug?
no progress on 3.0.3
Confirming both the initial report and @richs' comment about behaviour where clicking on input elements instantly submits the form.
(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.
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?
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.
status-thunderbird3.0: ? → wanted
Keywords: regressionwindow-wanted → helpwanted
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. :(
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.
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.
Thanks Ludovic. That'll give me something to read.
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.
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.
(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.
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.
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.
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?
(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
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?
That's the idea. set the review flag to ? and ask :standard8 that should do it.
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?
(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 ...
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;
Assignee: nobody → kay.wrobel

        Attachment #462418 -
        Attachment is obsolete: true

        Attachment #462918 -
        Flags: review?(bugzilla)
Keywords: helpwanted

    
    

    
  
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.

    
    

    
  
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...

    
    

    
  


  
Changed var target assignment to be same as in hRefForClickEvent. Changed open braces to be on same line as IF statement.

        Attachment #462918 -
        Attachment is obsolete: true

        Attachment #479074 -
        Flags: review?(bugzilla)

        Attachment #462918 -
        Flags: review?(bugzilla)

    
    

    
  
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...
Status: NEW → ASSIGNED

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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 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.

        Attachment #479074 -
        Flags: review?(bugzilla)
Assignee: kay.wrobel → bugzilla

          status-thunderbird3.0:
          wanted → ---

          status-thunderbird3.1:
          --- → wanted
Flags: wanted-thunderbird+

    
    

    
  
Mark: If there's anyway I can help, let me know.

    
    

    
  
> 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.

    
    

    
  
Er, "a response from the server".  ;)

    
    

    
  
Will there ever be any movement on this topic?

    
    

    
  
 
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.

    
    

    
  
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...

    
    

    
  
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.

    
    

    
  
(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"

    
    

    
  
Also how can i get 5.0 release source code ?

    
    

    
  
(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

    
    

    
  
(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 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 :-)

        Attachment #479074 -
        Flags: review?(mbanner)
Assignee: mbanner → kay.wrobel

    
    

    
  
(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.

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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"

    
    

    
  
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 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#

        Attachment #479074 -
        Flags: review?(mbanner) → review-

    
    

    
  
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...

    
  
Version: 3.0 → Trunk

    
    

    
  
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?

    
    

    
  
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...

    
    

    
  
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...).

    
    

    
  
Can't believe three years have passed, and this bug is still there...

    
    

    
  
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.

    
    

    
  
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.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Depends on: 782580
Resolution: --- → WONTFIX

    
    

    
  
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...

    
  
Assignee: kay.wrobel → nobody

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
(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?

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
Hi there!

I just stumbled over this bug in 2021 and was very close to file a new bug report on this :D For the record, I am using Thunderbird 78.6.1 on macOS Big Sur.


To be honest I did not follow the entire thread here. The observation I made is that if an HTML form is present within an HTML e-mail, TB sends the user to any external address even though external contents within e-mails are blocked once a text input field is clicked.


    

  1. In contrast to a Hyperlink where the user may expect a context switch "on click", the "on focus" of an input field should not send the user to a web page. Especially as we are talking about plain HTML here, no JavaScript or Styles.
    2. 

  2. In case of Hyperlinks, TB indicates where the user will be sent (preview of the URL bottom left corner) - this is also not the case here.
    3. 

  3. There is no requirement for the HTML form to have a submit button. The following HTML markup is totally sufficient:
    4. 



<form action='https://security.lauritz-holtmann.de/'>
    <input type='text' name='test'>
</form>



Thus, there is a high chance that an end-user can be tricked to unwillingly browse an attacker's website: The dream of every CSRF attacker.


Speaking for my self, I was very surprised when I noticed that HTML forms in e-mails are a thing. Guess I am too young and did not experience these glory days when they might have been used frequently :D From a privacy perspective, I am quite sceptical towards form elements in e-mail, especially since we learned with Efail that HTML content elements could be misused for shady stuff.


Suggested fix: Remove HTML forms. As they were broken at least for the last 11 years, no benign user seems to care about them. The current state is at most beneficial for scammers who want to trick innocent users to visit their website.


Best,

Lauritz



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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: