Closed Bug 1749757 Opened 3 years ago Closed 3 years ago

`Open with...` radio box focused, but not checked in "What should Thunderbird do with this file" dialog for saving/opening attachments - habitual users may fail to open attached files, PDFs etc.

Categories

(Thunderbird :: Preferences, defect, P2)

Thunderbird 91

Tracking

(thunderbird_esr91+ verified, thunderbird97 verified)

VERIFIED FIXED
98 Branch
Tracking Status
thunderbird_esr91 + verified
thunderbird97 --- verified

People

(Reporter: thomas8, Assigned: darktrojan)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [workaround and checking: see comment 6])

User Story

Paul wants more control over saving vs. opening attachments and has "Always ask" set for PDFs. The dialog no longer has a default set (this bug), so pressing Enter does nothing (but was working in TB 78). Paul starts crying that he can't open his attachments, and chosing `Open with...` is more clumsy than before, also because the dialog does no longer remember Paul's previous choice between `Open with...` and `Save File`.

:thomas8 says:
Everyday functionality - I recommend to fix this asap.
Already heard this from donor support: "Why can I not open PDF attachments from my email?" Such questions are hard to answer with trivial, yet cunning bugs like this.

Attachments

(5 files)

Regression. Not seen in TB 78.14.0. Seen in TB 91.5.0 (64-bit) on Win10, and Daily 98.0a1 (2022-01-11) (64-bit).

STR

  • Preferences/Settings > Files and Attachments: Set Portable Document Format (PDF) to Always Ask.
  • (Double-)Click on PDF attachment of received msg
  • Observe radio box status of ( ) Open with...
  • Press Enter

Actual

  • Open with... radio box focused, but not checked
  • OK button enabled, but pressing Enter does nothing - pretty irritating for unsuspecting users
  • Checking Open with... checkbox is clumsy with keyboard or requires extra click
  • Dialog does no longer remember the last choice between Open with... vs. Save File as it used to

Expected

  • Initially default dialog to Open with... Save File: this radio box must be focused and checked (as in TB 78)
  • Allow users to conveniently just press Enter if they are happy to use the currently selected option
  • Remember/persist last user choice in the dialog's radio group, between Open with vs. Save File (as in TB 78)

Here's the error log which comes with this bug.

User Story: (updated)

Note that this behaviour is specific to PDF. I tried with Word, Excel, JPG without any issue.

Habitual users can easily press Enter as they used to in TB 78 and nothing will happen as there's no default selection. Then they may think that they can't open their attachments.

Workaround for keyboard users

Press Arrow down and Arrow up keys until the appropriate radio box is checked, then press Enter.
Mouse users need to perform an explicit click on the appropriate radio box.

Verify your attachment settings and Thunderbird version

You can change your settings how to handle attachments of different types (PDF, odt, docx etc.):

  • ≡ > Preferences > General > Files & Attachments
  • Then e.g. for Portable Document Format (PDF), you can choose between several options:
    • Preview in Thunderbird (Thunderbird default)
    • Always ask
    • Save File
    • Use Adobe Acrobat (System default)
    • Use other...

These settings have been fixed recently for Thunderbird 91.4.1 (bug 1690395, fixed by bug 1737711), so please ensure that you have updated to the latest version of Thunderbird (currently TB 91.5.0):

  • ≡ > Help > About Thunderbird
Summary: `Open with...` radio box focused, but not checked in "What should Thunderbird do with this file" dialog for saving/opening attachments → `Open with...` radio box focused, but not checked in "What should Thunderbird do with this file" dialog for saving/opening attachments - habitual users may fail to open attached files, PDFs etc.
Whiteboard: [workaround and checking: see comment 6]
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

Thanks much Magnus for linking bug 1747361 where this was first reported 21 days ago.
In terms of bug management, even though it's just a day old, I think this bug is already in a much better state:

  • user story
  • more precise description / STR under our control
  • error log in comment 4
  • workaround and crowd control in comment 6

So I think our best foot forward is to consolidate and continue here.

Per earlier bug 1747361, comment 1, the regression occured between TB 91.4.0 and 91.4.1.
Per Magnus' knowledgeable confirmation in bug 1747361, comment 3, this is "likely from bug 1737711" which landed for 91.4.1.

Status: RESOLVED → REOPENED
User Story: (updated)
Priority: P3 → P2
Regressed by: 1737711
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
Component: Message Reader UI → Preferences
Assignee: nobody → geoff
Status: NEW → ASSIGNED

This fixes the error about browsing contexts and the bug disappears. IME the selection is reset to Save the first time and after that it remembers what you last chose.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/b568fbfc3072
Provide a browsingContext id to app launcher dialog when opening attachments. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch

Why isn't there a fix for the generally available 91.x ?

The bug has been introduced with 91.4.1 so I'd hope that it's also fixed in that branch.

(In reply to kr from comment #15)

Why isn't there a fix for the generally available 91.x ?

The bug has been introduced with 91.4.1 so I'd hope that it's also fixed in that branch.

If you take a look at the bug flags, you will see that we have status-thunderbird_esr91: --- → affected, so we marked this bug to be tracked for 91.
When a fix lands on trunk, we wait a small period of time for QA, then we uplift the patch to 91, so it will be available in the next 91 update.

Please, read the BMO guidelines to get acquainted with the various flags and the process: https://wiki.mozilla.org/BMO/UserGuide

Ah, thanks for the guidance - I just saw the ticket status "closed" which in other ticketing systems means "that's it". So, looking forward to the 91.x fix. :-)

Comment on attachment 9258761 [details]
Bug 1749757 - Provide a browsingContext id to app launcher dialog when opening attachments. r=aleca

[Approval Request Comment]
Regression caused by (bug #): bug 1737711
User impact if declined: no option selected when opening attachments, nothing happens when pressing enter with no choice
Testing completed (on c-c, etc.): landed last week
Risk to taking this patch (and alternatives if risky): low, but not zero

Attachment #9258761 - Flags: approval-comm-esr91?
Attachment #9258761 - Flags: approval-comm-beta?

Comment on attachment 9258761 [details]
Bug 1749757 - Provide a browsingContext id to app launcher dialog when opening attachments. r=aleca

[Triage Comment]
Approved for beta

Attachment #9258761 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9258761 [details]
Bug 1749757 - Provide a browsingContext id to app launcher dialog when opening attachments. r=aleca

[Triage Comment]
Approved for esr91

Attachment #9258761 - Flags: approval-comm-esr91? → approval-comm-esr91+

Further to this:
When you open an attachment, in an email you are about to send (IE: When you double check the correct attachment is attached) the prev radio button selection is present and works properly.

So the problem is narrowed down to only received or sent emails.
Emails yet to be sent are OK
Derrick

I hope I'm following along correctly.
Testing the 91.6.0 release candidate on Windows 10

  • I set the Action for the PDF Content Type to "Always Ask" in Preferences.
  • Opened a PDF attachment I received in an email and got the "What should Thunderbird do with this file?" prompt.
  • Selected Adobe Acrobat DC as the "Open with" application.
  • The radio button was filled in.
  • Tested with another PDF attachment and the radio button was still filled in.
  • Tested with other attachments and the radio button was filled in.

I'll let the reporter, kr or Derrick B verify that it is fixed for them.

Attached image radio-button.png

Filled in dot.

Not fixed.
I am on the latest Thunderbird release/update
Using Windows 7 Pro
All attempts to open attachments (in emails received or sent) do not show the radio button in the prev state
Emails not sent yet, show the radio button in the prev state

(In reply to Derrick B from comment #29)

Not fixed.
I am on the latest Thunderbird release/update
Using Windows 7 Pro
All attempts to open attachments (in emails received or sent) do not show the radio button in the prev state
Emails not sent yet, show the radio button in the prev state

Like I said in comment 28. I am testing the 91.6.0 release candidate, which should be out next week.

I've tested it with 91.6.1 on Windows 2012r2 & W10, double-clicking a .pdf directly in the mailbox view and also from an opened window with the message.

Both ways, it's working fine, the radio button is back on the last used option. Also it's again possible to simply hit 'enter' on that dialog to open the preselected option.

Attached image evidence.png

I confirm, it works W10, starting from 91.6.0

However there is another bug trying to open PDF-attachment when composing the message.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1698140

Please fix it accordingly.

In Windows 7. Ver 91.6.1 (32 Bit)
I confirm it is fixed.
I tried opening, and saving. Next time it remembered , respectively
Cheers

Verifying based on my observations and others comments.

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

Attachment

General

Created:
Updated:
Size: