User Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36

Steps to reproduce:

Inbound e-mail has video file (.mp4) attached and T-Bird asks which APP I want to use to open same.
I tic the appropriate box to answer.

Actual results:

Click to open video file, answer question from pop-up box and file opens OK.

The box is tic'd to use that same APP again ... yet the question box continues to open for all such files.

Expected results:

The choice of which APP to use should have been remembered.

In checking T-Bird Options that chosen APP ... IS selected.

So ... not sure why the prompt asking for which APP to use to open a video file is happening all the time with the most recent release.

Works for me on Windows 10 using the most recent release version 78.7.0.

You are using the 86.0b1 beta version?

Does the application appear in the Actions column for that Content Type under the Files & Attachments heading in Options > General?

I can reproduce testing with .jpg, .png, and .mp4 files in Thunderbird 86.0b1 and 87.0a1 on Windows 10 and Fedora 33 Linux.

Files & Attachments shows the correct Action for the corresponding Content Type.

Walt - The dialog that opens provides (as best I can determine) all the options needed to select to open the file.
Once selecting any given option the file opens just fine.

My question relates to the tic box for "Do this automatically for files like this from now on"

Once I tic that box I don't expect to be seeing that dialog again when opening the same type of file. However, the dialog is persistent for me.

I'm using TB version 86.0b1 (32 bit)

Windows 10 Pro
Version 2OH2
OS Build 19082.789

I can reproduce the problem and forgot to tick one box when confirming the bug report which I will correct now.

Still occurring with the 86.0b2 candidate for me on Windows 10 and Fedora 33 Workstation.

When I click "Cancel" in the second request for what application to use, then select another message I get this dialog.

Alice, any chance to get a regression window? TIA!

There are 2 regressions.
#1: Image attachments loaded in message reader pane instead of opened
#2: Bug #1 was fixed by Bug 1687847. However, this bug appears if turn on "Do this automatically for files like this from now on".

#1 Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=47627b7a5b34d04816233abe24bf4051b8ac807c&tochange=be365d09c14b55f717bdf633cf48dbb6a27a3754
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0478698744b1b970c65eefe277903ed457826b06&tochange=a3cd8f83fefafedaccd0c52a73ab001c510e63fe

#2 Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=f26eb6e2e0c549bad7a457ab6c6d84f06ec4e4c4&tochange=49c00a6f17ef9f3caded00b12215a62a431052fd
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=63534c66d7b813bf04d9753d942f59984c05b8a9&tochange=fddc94978eb7f42cca5d199b94164d133facc3e7

Suspect: Bug 1687847

Thanks!

FWIW - I still get the continual prompt of which APP to use to open a given file.

Using TBird 87.0b2 32-bit with Windows 10 Pro

Any progress for fix?

It isn't fixed in the 87.0b3 release candidate or the most recent 88.0a1 and is still "Unassigned" so nobody is fixing it at this time.

Bug 1687847 set the content disposition on attachment requests to force them to be treated as attachments (that is, show the save dialog) rather than loading inline. Looks like that currently means always show the save dialog because it's forced to open here (mReason is set to nsIHelperAppLauncherDialog::REASON_SERVERREQUEST here because of the disposition we set).

Somehow we need to have "we can handle this content type but we don't want to" and "follow the user's setting and don't ask about it". I'm tempted to just skip lines 1845-1849 with #ifndef MOZ_THUNDERBIRD but maybe we can do something cleverer and introduce a new REASON flag on nsIHelperAppLauncherDialog. Gijs, I wonder if you have any bright ideas here?

(Side note: this all just worked before we became multi-process, and then it stopped working even though all of it is in the parent process. I don't know why it worked before and not after.)

(In reply to Geoff Lankow (:darktrojan) from comment #13)

Somehow we need to have "we can handle this content type but we don't want to" and "follow the user's setting and don't ask about it". I'm tempted to just skip lines 1845-1849 with #ifndef MOZ_THUNDERBIRD but maybe we can do something cleverer and introduce a new REASON flag on nsIHelperAppLauncherDialog. Gijs, I wonder if you have any bright ideas here?

I do not. You're running into bug 453455. Firefox can't do the same thing (ie not ask) as long as Windows and Linux still put those files in the temp folder, risking data loss if users later want files they've opened directly. We're hoping to change that as part of an outreachy project later this year.

As noted by WaltS48 post above ...

I can confirm that the 'prompt for which APP to use' is still alive/well with thunderbird 88.0b3 (64-bit).

I'm using W-10 Pro

Just a follow-up:

Confirming that the 'prompt for which APP to use' is still alive and well. Thunderbird 89.0b4 (64-bit).

Using W-10 Pro

I still have the same problem, Thunderbird 89.0b4 (64-bit).
Windows 10 Home

(In reply to Kent Harker from comment #20)

I still have the same problem, Thunderbird 89.0b4 (64-bit).
Windows 10 Home

No need to reiterate that the problem still exists.

The bug is still, "Unassigned", and a fix is not imminent.

This won't get fixed in the 91 cycle, there's nothing we can do about it. It might be possible to prevent the checkbox from appearing, but I don't think that's been looked at yet.

This issue is also apparent when opening a webpage from an email - asked to do this from now (Open in the browser), but question is asked again the next time, selection is NOT remembered, same for Word and Excel files

This is on the macOS 10.15.7 en-UK, TB 91.0b6

So seems to be a more wide-spread issue

http links normally just open in the browser with no asking at all. If you get an ask, then probably you set something special (like handler for http in the attachments)

No issue opening links in an email here in the 91.0 release candidate on Windows 10.

So this is also a dupe of bug 453455 like bug 1725562 is a dupe of?

I am on TB 91.0.

I am having the same problem opening some attachments. For image files like .bmp, .jpg, etc. I get a pop up asking what program I want to use. This despite having a program defined for these types in the TB settings (Faststone Image Viewer). I tick the option to use the same program in the future, but next time I try I get the pop up again. The weird thing is that this doesn't happen for .pdf files... it opens in the program I put into the settings (PDF XChange Editor) just fine.

This didn't happen in TB 68 or TB 78 (or any earlier release I have used).

For me this is a new bug in TB 91.0. Do I need to open a new issue?

Bill

(In reply to wrhenshaw99 from comment #27)

I am on TB 91.0.

I am having the same problem opening some attachments. For image files like .bmp, .jpg, etc. I get a pop up asking what program I want to use. This despite having a program defined for these types in the TB settings (Faststone Image Viewer). I tick the option to use the same program in the future, but next time I try I get the pop up again. The weird thing is that this doesn't happen for .pdf files... it opens in the program I put into the settings (PDF XChange Editor) just fine.

This didn't happen in TB 68 or TB 78 (or any earlier release I have used).

For me this is a new bug in TB 91.0. Do I need to open a new issue?

Bill

No need to open a new bug report.

See Comment 22

Please excuse the question: What is wrong with the suggestion from comment #13 to disable that said block of code for Thunderbird, at least until a better solution is implemented? It works for us.

This is a regression of user experience without any user benefits, other than to bring Thunderbird into line with Firefox, where they have debated the issue for a decade without looking like getting resolution. I do not think this is an occasion where duping to a core bug is going to be in the least beneficial, as Mozilla's focus is not on Thunderbird and it's needs and a fix in a timeframe that would benefit Thunderbird 91 users is not going to be forthcoming unless the Thunderbird team take the bug and action it.

I would therefore ask that the bug be reopened and that some effort be expended to take whatever action is necessary to make the Thunderbird user experience in this independent of what for a mail client is a poor choice of actions. I note in Comment 13 that DarkTrojan has identified what appears to be the code causing the issue and offered a workaround to it being executed in Thunderbird. Perhaps this can be moved forward as a patch because the current approach is as squirrelly as the crazy Mac process of dumping all attachment on the desktop. Perhaps both issues can be managed by using user preferences.

So ... is this actually being worked on? Doesn't seem to be on anyone's 'concerned' list to be looked at.

I guess what I find frustrating is that it used to work just fine until the release of TB 86.

Since then ... I'm fortunate to have found the new soft-fork of Thunderbird that is called Betterbird and that client works just fine with these issues fixed.

Another question. Why is this marked as a duplicate of bug 453455? That refers to a problem in Firefox that started 13 years ago and this refers to a problem in Thunderbird which just started in versions after 78.13.

Changes to Thunderbird made that bug more exposed in Thunderbird. But those changes were necessary...

Why was this bug updated since it is closed (although I would argue that it shouldn't be closed)?

Are there any plans to ever fix this problem in Thunderbird (regardless of which Bugzilla number it is)?

Bill

Yet another report of the problem which is closed and made a duplicate of this closed problem. Why is no one actually trying to fix this problem? This is an ongoing issue with Thunderbird support. Actual problems are not fixed for years while unimportant cosmetic changes are made to the UI instead. Why don't they fix actual problems before making unnecessary cosmetic fixes?

Bill

(In reply to wrhenshaw99 from comment #40)

Yet another report of the problem which is closed and made a duplicate of this closed problem. Why is no one actually trying to fix this problem? This is an ongoing issue with Thunderbird support. Actual problems are not fixed for years while unimportant cosmetic changes are made to the UI instead. Why don't they fix actual problems before making unnecessary cosmetic fixes?

Bill

Bill,

In the meantime use Betterbird. A fork of T-Bird that has most (if not all) of the broken items in T-Bird fixed. I've been using for some time and it works very well.

https://www.betterbird.eu/index.html

Cheers,

Nolan K.

What's the point of pointing to regressions if they are closed with "won't fix"?

(In reply to marrtins from comment #47)

What's the point of pointing to regressions if they are closed with "won't fix"?

Apologies sir if I did something incorrect there.

I figured since those versions were betas and no longer being developed, they would be "wontfix".

I won't touch the bug report next week to add version 95 and won't wontfix version 94.

Thank you for your guidance.

This gets back to the same questions I have asked several times and nobody ever answers.

If the problem is still occurring and people are reporting it then why is it closed? Why are new reports of the bug marked as duplicates of this one which is closed? It is still a problem, why isn't there an open issue to correct the problem?

Bill

(In reply to wrhenshaw99 from comment #49)

This gets back to the same questions I have asked several times and nobody ever answers.

If the problem is still occurring and people are reporting it then why is it closed? Why are new reports of the bug marked as duplicates of this one which is closed? It is still a problem, why isn't there an open issue to correct the problem?

Bill

I don't know why they are still being marked as duplicates of this one, marked as a duplicate of bug 453455.

It looks like Mozilla is working on the open issue.

"You can configure files to always open with external applications in Nightly settings and Nightly will actually do that for all files (fixing a long-standing bug)"

REF: [Public] Nightly changes to the Firefox download flow

For clarity, so it is visible that this is an open issue for Thunderbird but will be fixed by Firefox, reopening and setting dependency on bug 453455.

For clarity, it is known that the behavior changed in version 91. But the fix is expected to come via bug 453455.

Wayne,

Thank you for that clarification.

Bill

Lack of movement on this bug certainly seems to indicate that the long-overdue fix is still going to be a long time coming.

Whether it is FF or TB someone/somewhere/somehow should get this repaired.

I've shared this link before and I'll share it again ... there is a fork of TB called Betterbird and it has the bugs noted in TB all repaired. I've been using Betterbird for many months and its operation is seamless from TB ... save for that I can open external file attachments without any issues.

https://www.betterbird.eu/index.html

Give it a try and use until TB / FF gets their bugs fixed.

Cheers,

Nolan K.

(In reply to Wayne Mery (:wsmwk) from comment #51)

For clarity, so it is visible that this is an open issue for Thunderbird but will be fixed by Firefox, reopening and setting dependency on bug 453455.

Is there a meta bug tracking what bugs have fixes available but are in limbo because we're waiting for Firefox to fix them instead? If not I suggest you create one so that its easier to monitor how well that works out.

BetterBird submits bug fixes upstream. Are there any other forks or email clients based on Thunderbird that do the same thing? Fossamail and Interlink are discontinued, Thunderbird is being provided instead of IceDove by Debian and SoftMaker Office appears to have stopped including a customized version of Thunderbird but perhaps PostBox. I remember reading somewhere about the project and PostBox working together on some issues.

14 TB duplicates here (33 FF duplicates on 13-year-old FF Bug 453455) and counting. In terms of UX, this isn't nice at all. Any hack to fix this regression in TB91 would probably be worth it.

(In reply to Geoff Lankow (:darktrojan) from comment #13)

Somehow we need to have "we can handle this content type but we don't want to" and "follow the user's setting and don't ask about it". I'm tempted to just skip lines 1845-1849 with #ifndef MOZ_THUNDERBIRD but maybe we can do something cleverer and introduce a new REASON flag on nsIHelperAppLauncherDialog. Gijs, I wonder if you have any bright ideas here?

Geoff, given the significant UX impact, can we try your idea to just skip 4 lines of code for Thunderbird to make this work again?
Which apparently fixes the symptoms per Zoe's comment 30.

(Side note: this all just worked before we became multi-process, and then it stopped working even though all of it is in the parent process. I don't know why it worked before and not after.)

Bug 773942 might have clues as well?

We're looking into uplifting bug 1737711, since I've already had to go to that effort and it should solve this bug.

(In reply to Geoff Lankow (:darktrojan) from comment #61)

We're looking into uplifting bug 1737711, since I've already had to go to that effort and it should solve this bug.

Awesome, thanks for rapid reply. Fingers crossed.

I am facing this same issue with xls, xlsx attachments. I have tried multiple latest versions of TB. Currently, I am 91.4.0 ( on CentOS 7.6).

Please suggest if there is any way to fix this.

Did something change in 91.4? I'm no longer having this issue.
Attachments are opened in default aplications. There is side issue that attachemts aren't read-only any more, but that doesn't bother me. :)

Fantastic. Working for me now as well.

It wasn't mentioned in the release notes. Thanks for letting us no.

Bill

Thanks for letting us know.

Fixed by bug 1737711.

Verified by wrenshaw99, Mihovil and me.

Fixed by bug 1737711, which has thunderbird95 aka 91.4 verified fixed.
So as stated by comment 65, this bug is fixed starting from TB 91.4.1 (bug 1737711, comment 39).
Unfortunately, the thunderbird95 flag is no longer available for this bug.

Hi Mathew, why did you remove the dependency on bug 453455?
Maybe not a strict technical dependency, but as TB uses FF/toolkit platform, these bugs are definitely related and making the relationship explicit will be helpful for both sides... At the very minimum, we'd need to preserve a see-also link...