Open Bug 1740841 Opened 4 years ago Updated 2 years ago

(Intermittent) "Always Open Similar Files" is shown as selected (extensions type not added)

Categories

(Firefox :: Downloads Panel, defect, P2)

Firefox 96
Desktop
Windows
defect
Points:
3

Tracking

()

Tracking Status
firefox-esr91 --- unaffected
firefox94 --- unaffected
firefox95 --- disabled
firefox96 --- disabled
firefox97 --- disabled
firefox98 --- wontfix
firefox99 --- affected

People

(Reporter: aflorinescu, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [fidefe-mr11-download])

Attachments

(3 files, 1 obsolete file)

[Description:]

Similarly with bug 1740840 for the "Always Open Similar Files", but with the twist that when reproducible it will show "Always Open Similar Files" as selected.

[Environment:]

Windows 10
96.0a1 20211111211702

[Steps:]
  1. Open Firefox
  2. Access https://ftp.mozilla.org/pub/firefox/releases/0.10.1/
  3. Download a tar.bz
  4. In the download panel, right Click on the file to check the availability of the "Always Open Similar Files"
  5. Restart the browser.
  6. Open Tools/Downloads.
  7. Right click on the downloaded file.
[Actual Result:]

In some conditions (?) the "Always Open Similar Files" appears as already checked, although it has not been checked, nor the browser behaves as such.

[Expected Result:]
[Note:]

I reproduced the above scenario once in the Downloads Panel as well, but I haven't caught reliable STR to reproduce either.

Blocks: 1740701
No longer blocks: 1740705
Priority: -- → P2
Whiteboard: [fidefe-mr11-download]
Whiteboard: [fidefe-mr11-download] → [fidefe-mr11-download]
Whiteboard: [fidefe-mr11-download] → [fidefe-mr11-download]
See Also: → 1740840
Assignee: nobody → kpatenio
Status: NEW → ASSIGNED

Tried this out with the latest version of Nightly I have (96.01 2021-11-26) with Windows 10. In about:preferences, I noticed that the action for tar content types appear as Always ask, but behave as if we're opening with a default app. This can be seen on the screenshot I attached, where the incorrect icon is being displayed for Always ask. This could explain why the checkmark appears in the context menu.

It's possible that this issue is related to Bug 1738111 and Bug 1738706, where the same exact issue came up for .Torrent files after using Always Open Similar Files. In HandlerService.js, we read the extensions and set up the handlers.

@aflorinescu - do you get same icon + alwaysAsk issue for tar files after enabling Always Open Similar Files? If so, it would help if you could attach the handlers.json file for the profile you used. The easiest way to do this (that I know of) is to do the following:

  1. Navigate to about:support on Firefox
  2. The support page will open. Go down to Profile Folder
  3. Click Open Folder
  4. The Windows Explorer will open the folder for your current profile. Find handlers.json here.
Flags: needinfo?(adrian.florinescu)
Attached file handlers.json

Interesting, I'm not sure why in your case you see it as a 7zip file, but it defaults to always ask. Might be because on my available W10 machines I've been messing with default programs quite a lot.

What I can confirm though is that if I remove all the arhive managers, basically forcing windows to have no defaults for the tar or gz, then indeed I will have the Always ask but with the incorrect icon and it will continue to behave as we're opening with default app (even thought there's none anymore). - I'm attaching a handlers.json from this case (both gz and tar)

I have a susspicion that the original reported behavior would be reproducible with a clean windows install that doesn't have or had a default app for the extension @ hand and which does reproduce bug 1740840.

Flags: needinfo?(adrian.florinescu)
Severity: S2 → S3
See Also: → 1742693

(In reply to Adrian Florinescu [:aflorinescu] from comment #2)

Created attachment 9252814 [details]
handlers.json

Interesting, I'm not sure why in your case you see it as a 7zip file, but it defaults to always ask. Might be because on my available W10 machines I've been messing with default programs quite a lot.

What I can confirm though is that if I remove all the arhive managers, basically forcing windows to have no defaults for the tar or gz, then indeed I will have the Always ask but with the incorrect icon and it will continue to behave as we're opening with default app (even thought there's none anymore). - I'm attaching a handlers.json from this case (both gz and tar)

I have a susspicion that the original reported behavior would be reproducible with a clean windows install that doesn't have or had a default app for the extension @ hand and which does reproduce bug 1740840.

Thanks so much for doing that @aflorinescu. Apologies for the delayed response. I don't see anything off with the handlers.json that you attached. And getting the always ask icon issue seems to occur when there is no default app available for a file extension (or at least that's one way), so it makes sense how you were able to reproduce it. Similar behaviour is found elsewhere too.

I've decided to retry the STR again in a Windows VM using a .tar.bz2 file. I'm not quite sure how to verify the checkmark in particular, since there are still issues with the visibility for "Always Show Similar Files" on Windows. Findings + steps:

  1. Went to the same link in STR and downloaded the tar.bz2 file.
  2. The "Always Open Similar Files" action was available when right clicking the downloaded item on the downloads panel.
  3. Closed Nightly, opened the downloads window (ex. ctrl + j), and right clicked the downloaded item.
  4. Noticed that "Always Open Similar Files" was no longer visible.

Setting a default app via the Windows setting "Choose default apps by file type" seems to make no difference. I feel this may first require a bigger fix from bug 1659008 or bug 1738918 that revises how we associate download actions to file types.

Depends on: 1738918
Points: --- → 3
No longer blocks: 1733587
Assignee: kpatenio → nobody
Status: ASSIGNED → NEW

Firefox 98 shipping soon, updating flags.

Attachment #9387481 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: