533462 - Impossible to open a .txt and .html attachment with an external editor.

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[Federico]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; it; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4
Build Identifier: Open .txt attachment with external editor (nottepad)

If you double-click a .txt attachment the editors starts but you get an error message (For Notepad: The system cannot find the path specified).

Reproducible: Always

Steps to Reproduce:
1.Select a received message with a .txt attachment.
2.Double click on the attachment.
3.Error with Notepad, blank with TextEdit (Mac) or Notepad++.

Actual Results:  
Nothing (error).

Expected Results:  
Edit the attachment in external editor.

Comment 1

[Federico]

TB 3.0 RC2 (Mac & Winsows 2003 Server) + RC3 (Mac)

Comment 2

[Giuliano Masseroni [:jooliaan]]

I have followed the steps described by Federico and I can confirm tha bug on Windows Vista Business SP2, Windows Vista Home Premium SP2, Windows XP Professional SP3 and Windows 7 Ultimate. All the OSes were tested with Thunderbird 3 RC2.

Comment 3

[Underpass]

Attachment: TXT attachments in Linux

This is what happens in Linux

Comment 4

[Underpass]

Just tried in Linux and the application doesn't seem to know how to handle TXT files.
The screenshot is in Italian but I think it is rather understandable.

I'm using Thunderbird 3.0 RC3-candidate

Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

on Debian (Testing)

Comment 5

[Francesco Lodolo [:flod]]

I think that this bug is a duplicate of bug 532779, especially considering the latest update to its summary (added "Unable to open text attachment by external program").

Comment 6

[Giuliano Masseroni [:jooliaan]]

The same issue is reproducible also with outgoing emails, which is quite dangerous since it is nearly impossible to check what you are sending.

Comment 7

[Mark Banner (:standard8)]

Too late for blocking 3.0, we'll consider it for the first point release though.

Comment 8

[Giuliano Masseroni [:jooliaan]]

As per Ludovic request I post here below the following results obtained by checking the nightly builds:

The last nightly build working properly is:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6pre) Gecko/20091109 Shredder/3.0pre

The first nightly build showing the regression is:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6pre) Gecko/20091110 Shredder/3.0pre

Comment 9

[Ludovic Hirlimann [:Usul]]

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-11-09&enddate=2009-11-10 isn't very talkative top me

Comment 10

[Underpass]

Hello, 
Just to be sure, I double checked the test I made to identify the build. Just downloaded

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6pre) Gecko/20091109 Shredder/3.0pre

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6pre) Gecko/20091110 Shredder/3.0pre

and again I did not found the problem in the former one but only in the latter one.

Comment 11

[WADA:World Anti-bad-Duping Agency]

See bug 532779 comment #7 and bug 532779 comment #8 for parameter passed to external program upon "Open" of text attachment. Passed parameter example;
> mailbox:///C|/Documents%20and%20Settings/wada/Application%20Data/Thunderbird/Profiles/wxkq5msh.Gmail-IMAP/Mail/Local%20Folders/Inbox?number=4444260&part=1.3&filename=imap-log-2.txt&type=text/plain&filename=imap-log-2.txt

Comment 12

[WADA:World Anti-bad-Duping Agency]

CC-ing to David. Do you have time to analyze IMAP log?

Comment 13

[Phil Lacy]

Attachment: example of good and bad attachment dialogs

Created an attachment (id=416515) [details]
OpenAttachment popups

Attachments open different popups 
one works for example like pdf's or jpgs or zip files.

The other doesn't like txt files, eml files.

If this fix is obvious to someone let me know or take over assignment because it will take some digging if I try it.

Comment 14

[WADA:World Anti-bad-Duping Agency]

Ignore my comment #12, please. That's for other bug. Sorry for spam.

Comment 15

[Francesco Lodolo [:flod]]

(In reply to comment #9)
> http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-11-09&enddate=2009-11-10
> isn't very talkative top me

Maybe I'm wrong, but since those builds are 3.0pre, shouldn't you be watching comm-1.9.1?
http://hg.mozilla.org/releases/comm-1.9.1/pushloghtml?startdate=2009-11-09&enddate=2009-11-10

Comment 16

[Francesco Lodolo [:flod]]

Did some tests on trunk but I found the same window

Working fine
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091109 Shredder/3.1a1pre

Not working
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091110 Shredder/3.1a1pre

If I checked correctly, there are six bugs in common between comm-central and comm-1.9.1: 515650, 521603, 524667, 252302, 527198, 527405.

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
>(no problem)
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6pre) Gecko/20091109
> Shredder/3.0pre
> (problem started to occur)
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6pre) Gecko/20091110
> Shredder/3.0pre

Build time of 20091110 build.
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2009/11/2009-11-10-03-comm-1.9.1/
> thunderbird-3.0pre.en-US.win32.zip 10-Nov-2009 05:00 12M

(In reply to comment #15)
> http://hg.mozilla.org/releases/comm-1.9.1/pushloghtml?startdate=2009-11-09&enddate=2009-11-10
This is for next.
> Changes pushed after 2009-11-09 00:00:00, before 2009-11-10 00:00:00
"before 2009-11-11(00:00:00)" or "before 2009-11-10 05:00:00" should be checked.

Search between 2009-11-09(00:00:00) and 2009-11-10 06:00:00.
> http://hg.mozilla.org/releases/comm-1.9.1/pushloghtml?startdate=2009-11-09&enddate=2009-11-10+06%3A00%3A00
> Changes pushed after 2009-11-09 00:00:00, before 2009-11-10 06:00:00
=> Bug 516776(Tue Nov 10 01:49:04 2009 -0800) additinally hits.

Comment 18

[Phil Lacy]

the new contenthandler in bug 516776 may be the culprit but Venkman doesn't load it so it is a little difficult to debug.

I added html files to the description. It appears the problem is TB handling the txt and html files with the url while the .pdf jpg and other types are opening as files through the regular handler dialog.

Maybe excluding the new nscontenthandler from handling attachments would work if that's in fact the problem and if that's possible.

Comment 19

[Mark Banner (:standard8)]

Phil, have you got a link to the code where we start the load for the attachments?

Comment 20

[Phil Lacy]

Attachment: jsdump of bad dialog

I just learned how to do the jsdump from Joshua last night so I haven't had time to see if this is getting everything.

Doing it on the good handler terminates the debug session so I couldn't get far.

Comment 21

[Phil Lacy]

I'm breaking here http://mxr.mozilla.org/comm-central/source/mozilla/docshell/base/nsDocShell.cpp#1158 when I do the js stack dump

Comment 22

[Phil Lacy]

Mark, it appears to me the new contentHandler registers itself for content of type text/plain or text/html.

Is it possible to unregister the mailContentHandler before opening attachments and then re-register it.  That handler is using the dialog.xul to ask how to open the mailbox url. whereas the old one that is still handling other  content types saves a temp file and brings up a handler for the file.

Comment 23

[intendentedelleacque]

Maybe this can be useful to solve this bug: deleting (or renaming) the file "mailContentHandler.js" in "components" directory, the bug will disappear.

Comment 24

[Mark Banner (:standard8)]

(In reply to comment #23)
> Maybe this can be useful to solve this bug: deleting (or renaming) the file
> "mailContentHandler.js" in "components" directory, the bug will disappear.

Which will break clicking on links in other areas of Thunderbird, and hence is not recommended. We will be fixing this for the first security release (3.0.1), so please be patient.

Comment 25

[intendentedelleacque]

(In reply to comment #24)
> Which will break clicking on links in other areas of Thunderbird, and hence is
> not recommended. We will be fixing this for the first security release (3.0.1),
> so please be patient.

I'm not impatient, I just wanted to add something that *maybe* could be useful... next time I'll avoid it.
Anyway, clicking on links in mail content works for me also without that file (on Linux)

Comment 26

[Ludovic Hirlimann [:Usul]]

https://litmus.mozilla.org/show_test.cgi?id=9790

Comment 28

[Mark Banner (:standard8)]

Attachment: Possible fix

I'm thinking this is the probable fix. The issue is that we registered the mailContentHandler to deal with text/plain and text/html being sent internally intended for opening in a new window. However we didn't take account of the attachment case.

When we load attachments, they will come from an imap or mailbox scheme, when we're loading links etc they will be http or https. So this does the necessary checks and if its an internal link, the handler throws and lets something else deal with it.

I'm not quite sure yet if the checks should be against internal urls or against external urls. I've got a bit more thinking to do about it.

I'll do some try server test builds anyway so that folks can try them out.

Comment 29

[Phil Lacy]

can we do a check for protocol scheme

Comment 30

[Mark Banner (:standard8)]

(In reply to comment #29)
> can we do a check for protocol scheme

That's what I'm doing.

Comment 31

[Phil Lacy]

ignore that, I guess I should have looked at the patch

Comment 32

[Mark Banner (:standard8)]

Try server builds now available:

http://s3.mozillamessaging.com/build/try-server/2009-12-21_04:[e-mail]-st8-fix-attachments-1/[e-mail]2
http://s3.mozillamessaging.com/build/try-server/2009-12-21_04:[e-mail]-st8-fix-attachments-1/[e-mail]
http://s3.mozillamessaging.com/build/try-server/2009-12-21_04:[e-mail]-st8-fix-attachments-1/[e-mail]

It'd certainly be useful to get some testing on these. Especially with different kind of links/files in the attachments etc.

Comment 33

[ronald.canete]

Hi Mark.. The server builds 3.01pre is working, it can now open the html attachment, on your final release possible to add the mht extension because I can not open it as attachment. Thanks.

Comment 34

[Ilja Sekler]

Confirming that the patch <https://bugzilla.mozilla.org/attachment.cgi?id=418402> fixes the issue with attached text (text/plain) and html (text/html) files and doesn't break a big variety of other types incl. emails forwarded as attachments (.eml). Tested with

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b6pre) Gecko/20091231 Lightning/1.1a1pre Thunderbird/3.1a1pre

SourceStamp=20c2d9e8e9b4+

Comment 35

[Mark Banner (:standard8)]

Comment on attachment 418402 [details] [diff] [review]
Possible fix

At the moment I believe writing a test case for this would be hard (as we have no existing cases), and I'd really like to get this in for 3.0.1.

Therefore I'm going for double-reviewers and if we take it I'll file a bug for getting the appropraite infrastructure and test case written.

Thanks to Ilja for the extra testing.

Comment 36

[David :Bienvenu]

I tried this with a .txt attachment - it's a big improvement. I did notice that the .txt file opened in notepad and then the download manager said it was scanning the file for viruses, which seemed a bit backwards, but maybe that's the way the download manager works...

Comment 37

[K.Shi]

In Environment Windows XP SP2 + TB3.0
I cant open txt,html,csv etc texture file by system app(notepad) nor external app
(editplus, ie, ultraedit etc).

with notepad, it said no path found.
with external app, it opened but with strange warning like "mailbox:\\\c|\Documents%20and%Settings\...."

TB2.0 never happened.. :-[

------------------------------------------------------------------------
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

Comment 40

[Mark Banner (:standard8)]

Checked into trunk (3.1x/3.2x) builds: http://hg.mozilla.org/comm-central/rev/2aa1b7a5fd3d

I'll look at 3.0.x later.

Comment 41

[Mark Banner (:standard8)]

Comment on attachment 418402 [details] [diff] [review]
Possible fix

a=Standard8 (Medium risk, tested patch, with litmus tests, but high value to users)

Comment 42

[Mark Banner (:standard8)]

Checked into branch for 3.0.1pre:

http://hg.mozilla.org/releases/comm-1.9.1/rev/33b8322046c6

Comment 43

[Ludovic Hirlimann [:Usul]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100110 Shredder/3.0.1pre