User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Detached attachment doesn't open on double-click in TB 91 any more. This was working in TB 78.

STR:
Send yourself an e-mail with an image attachment (or use any e-mail that has an image attachment).
On the received e-mail, detach the image attachment to the desktop or a folder.
The attachment now shows as a link. Single or double-click.

Actual results:

Nothing happens.

Expected results:

Attachment should open as it did in TB 78.

Variation: If you use a PDF attachment, a detached PDF attachment will still open in the internal PDF viewer. If in preferences, an external PDF viewer (like Adobe) is configured, opening the attachment fails just like it fails for images.

Alice, could you find the regression for us, please.

(In reply to Rachel Martin from comment #1)

Alice, could you find the regression for us, please.

Could you please detail of steps.

detach the image attachment to the desktop or a folder

How ?

Single or double-click.

On what?

Detach: Right click on the attached image in the attachment area, "detach".
Double-click: On the detached attachment which then shows as a link in the attachment area.

(In reply to Rachel Martin from comment #3)

Detach: Right click on the attached image in the attachment area, "detach".
Double-click: On the detached attachment which then shows as a link in the attachment area.

Thanks,

However, I cannot reproduce the issue in TB91.2.1 and Daily95.0a1(20211028100241) Windows10.

Detach: Right click on the attached image in the attachment area, "detach".

Detach Attachment dialog popup and click on Save button.
And then Confirm dialog popup, click on Ok or Cancel button.
The detached image is saved as an image file in the Windows local folder as expected.

Double-click: On the detached attachment which then shows as a link in the attachment area.

Opening xxx.jpg helper dialog popup, choose Seve File radio button, click on Ok button.
Enter name of file to save to... dialog popup and click on Save button.
The detached image is saved as an image file in the Windows local folder as expected.

Right, the detach part works. Using 91.2.1, double-clicking on to the detached image attachment does nothing, "Open" from the context menu also does nothing. This is on a new profile.

This is how it looks like after detaching.

(In reply to Rachel Martin from comment #5)

Right, the detach part works. Using 91.2.1, double-clicking on to the detached image attachment does nothing, "Open" from the context menu also does nothing. This is on a new profile.

I could not reproduce.

(In reply to Rachel Martin from comment #6)

Created attachment 9248471 [details]
2021-10-29 23_15_52-Window.png

This is how it looks like after detaching.

I could not reproduce.

Does your screen look the same or similar to the screenshot from comment #6?

(In reply to Rachel Martin from comment #8)

Does your screen look the same or similar to the screenshot from comment #6?

No.

Well, then the detach didn't work as expected. The steps of "Detach..." (context menu), "Save" on the file picker and then confirm lead to the attachment being removed from the e-mail and replaced by a link. When hovering the link, you see the link target in the status bar, something staring with file://. There's also a right-click menu with "Open", "Save As" active and "Delete", "Detach" inactive, since it's already been detached. That's standard behaviour for years. The subject of the bug is what happens if you (double-)click the link or use "Open" from the menu. Tested on local and IMAP folder.

Can you please attach a screenshot of the message after the detach operation and the context menu you're getting.

(In reply to Rachel Martin from comment #10)

The steps of "Detach..." (context menu), "Save" on the file picker
and then confirm lead to the attachment being removed from the e-mail and replaced by a link.
When hovering the link

Ah,
Double-clicking on to the detached image attachment in comment#3,
You mean
Double-click the link(replaced by the link shown in the steps above comment#10.) in the attachment list. I thought it was about double-clicking on the removed local files in the HDD.

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

Suspect: Bug 1683787

Daily95.0a1 debug build(20211029095932) shows the following logs when Double-click:
[Parent 9700, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED): file /builds/worker/checkouts/gecko/comm/mailnews/base/src/nsMsgUtils.cpp:145
[Parent 9700, Main Thread] ###!!! ASSERTION: Attempt to load a non-authorised load in the parent process: file:///D:/downloads/00.jpg: 'false', file /builds/worker/checkouts/gecko/netwerk/ipc/ParentProcessDocumentChannel.cpp:69

Hi Alice, many thanks for finding the regression. Sorry that the steps weren't clear.

So this appears to be a E10S problem. When switching off browser.tabs.remote.autostart and extensions.webextensions.remote to disable E10S (see https://mail.mozilla.org/pipermail/tb-planning/2021-January/008123.html) it starts to work again.

When detached to file and external url attachment UI was implemented, it was designed to behave like links, ie 1 click performs the action. The poor attachment list redesigns have ruined the ergonomic. More clicks, contextmenus, etc are unquestionably worse.

Working in TB 95 beta 3, likely fixed by bug 1737711.

(In reply to Rachel Martin from comment #15)

Working in TB 95 beta 3, likely fixed by bug 1737711.

Is fixed in 91.4.1 as well.