Closed Bug 1738706 Opened 3 years ago Closed 3 years ago

Newly created Content Type action does not match "Always Open Similar Files"

Categories

(Firefox :: Downloads Panel, defect, P1)

Firefox 95
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox95 --- disabled
firefox96 --- affected

People

(Reporter: Fanolian+BMO, Assigned: kpatenio)

References

Details

(Keywords: nightly-community, Whiteboard: [fidefe-mr11-downloads])

Attachments

(2 files)

Attached file handlers.json

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
Build ID: 20211101084651

Steps to reproduce

  1. In a new profile, make sure browser.download.improvements_to_download_panel to true.
  2. Go to Settings > General > Applications. Check that there is no entries for Content Type ZIP Archive.
  3. Download any .zip file, e.g. https://ftp.mozilla.org/pub/firefox/nightly/2021/11/2021-11-01-08-46-51-mozilla-central/jsshell-win64-aarch64.zip
  4. In the Downloads button on toolbar, right click the downloaded .zip and enable Always Open Similar Files.
  5. Reload the Settings page. Observe the entry for ZIP Archive.

Actual result

The Action for ZIP Archive is labelled as Always ask even though .zip files will directly open in external software, e.g. Windows Explorer.

I have attached a handler.json that represents the state right after I enable Always Open Similar Files.

Additional bugs

In Settings, if I switch the action for ZIP to Use Windows Explorer or other supported software, the tick for Always Open Similar Files is lost.
I can only get back the tick by pressing Always Open Similar Files again. This, however, results in two possible cases:

  1. Reset ZIP archive to Always ask. Or
  2. Create a new zip archive (in lowercase) and set the action to open my default zip program, 7-zip.

I haven't figured out how to reliably recreate case 2 yet.

Flags: needinfo?(gijskruitbosch+bugs)
Has STR: --- → yes

:Fanolian+BMO, if you think that's a regression, could you try to find a regression range using for example mozregression?

I haven't figured out how to reliably recreate case 2 yet.

Restarting the browser and select Always Open Similar Files again will create zip Archive (lowercase zip).

The synchronisation issue between Always Open Similar Files check mark and Settings > Applications is more unreliable than I think, especially when ZIP Archive and zip Archive co-exist. It should deserve a separate bug.
But it's 1am in my region and I may not be available for another 20 hours to file a new bug for it. Anyone please feel free to file a bug for me. Thanks a lot.

Katherine, do you have time to investigate this?

Blocks: 1733587
Depends on: 1731086
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(kpatenio)
Whiteboard: [fidefe-mr11-downloads]

(In reply to :Gijs (he/him) from comment #3)

Katherine, do you have time to investigate this?

For sure. Will look into this.

Flags: needinfo?(kpatenio)
Assignee: nobody → kpatenio

As it turns out this is an old bug that is unrelated to the works done in bug 1710926, or the "Always Open Similar Files" option. browser.download.improvements_to_download_panel, however, slightly changes how the bug behaves.
It was originally regressed in around 2019-09-27 to 2019-10-10 (autoland builds were not available to pinpoint the regression range). Bug 1586355 is the most likely regression.

I guess the Applications part in Settings was heavily underused until browser.download.improvements_to_download_panel was flipped to true. Or this bug is too minor (before bug 1732347) or rare that no one bothered to file a bug for it.
P.S. Bug 1738111 comment 4 describes the same issue.

browser.download.improvements_to_download_panel = false (the way it used to be)

It affects only 7-zip and only when it is the default zip program (tested on v19.00 and v21.03beta); but that's the only zip program I have installed.
Choosing Windows Explorer or other pre-defined helper applications, e.g. notepad, wordpad, does not exhibit the bug.

browser.download.improvements_to_download_panel = true

It affect both Windows Explorer and 7-zip. I cannot test other non zip programs because I cannot choose them when I enable "Always Open Similar Files".

Attached image Wrong action icon.png

The icon for the actions of newly created Content Types are wrong too.
This will be fixed by switching the action to Save File and back.

Severity: -- → S2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1

Sorry for the lack of updates recently. I've followed the reproduction steps with a new profile on windows 10 using Nightly 96.0a1. I have also installed 7zip and made it my default application for .zip files for the purposes of testing. In the Nightly settings applications table, the Content Type appears as ZIP Archive.

I'm unable to reproduce the following issues:

  1. seeing incorrect icons as shown in this image (although it is strange that this happened)
  2. Always ask appearing after selecting Always Open Similar Files for a zip file; for me, it appears as Use Applications\7zFM.exe (default) instead.

@Fanolian - are you able to reproduce this with a new profile using the latest version of Nightly?

As for the checkmark not appearing after selecting another app (Ex. use Windows explorer) within the table, this may be because 7zip is registered to be the default app for .zip files on Windows 10; for clarity, I set my default on Windows 10 via the following:

  1. right click a downloaded .zip file on File Explorer
  2. select Properties menu item
  3. change Opens With to 7-Zip File Manager (in my 7-zip folder, I selected it's 7zFM.exe)
  4. save changes

I noticed that by selecting another app like Windows Explorer within the Nightly settings applications table, the checkmark will not appear because Windows Explorer is not registered as a default app on Windows 10. Always Open Similar Files always reads whatever is set as a default app according to your OS, and not in Nightly settings. In addition, enabling Always Open Similar Files will always set the Action to whatever is your default app (thus, it will overwrite a previous action like Windows Explorer or Always ask). Given all this, I can see why this workflow may not be immediately clear/obvious (and can be confusing). Perhaps some changes can be made to improve this experience?

I also noticed something interesting while playing around with this. If I changed my default Windows 10 app for .zip files to Windows Explorer, the Content Type changes to Compressed (zipped) folder, and the Action changes to Use Windows Explorer (default). If I change the Action to Use Windows Explorer (non default version), the checkmark will not show. While not "wrong" since it will only work for the "default" version, this can be still be confusing.

Flags: needinfo?(Fanolian+BMO)

I can still reproduce comment 0 in a new profile in 96.0a1 (20211101215926, 20211103213618, and 20211104094642).
However due to the quirks on my computer I've seen when testing bug 1738950 (especially bug 1738950 comment 3), this issue may attributed to some unknown bad configurations on my system.

@:Virtual I see you describe a similar issue in bug 1738111 comment 4 and bug 1738111 comment 6. Can you still reproduce this?

I also noticed something interesting while playing around with this. If I changed my default Windows 10 app for .zip files to Windows Explorer, the Content Type changes to Compressed (zipped) folder, and the Action changes to Use Windows Explorer (default). If I change the Action to Use Windows Explorer (non default version), the checkmark will not show. While not "wrong" since it will only work for the "default" version, this can be still be confusing.

This is probably what I saw (but not anymore) in bug 1738950.

Flags: needinfo?(Fanolian+BMO) → needinfo?(Virtual)

(In reply to Fanolian from comment #8)

@:Virtual I see you describe a similar issue in bug 1738111 comment 4 and bug 1738111 comment 6. Can you still reproduce this?

Yes. I can still reproduce the issue in bug #1738111 in Mozilla Firefox 96.0a1 (2021-11-04), even after deleting "handlers.json" file from Mozilla Firefox profile folder or in new Mozilla Firefox profile.

Flags: needinfo?(Virtual)

(In reply to Fanolian from comment #6)

Created attachment 9248890 [details]
Wrong action icon.png

The icon for the actions of newly created Content Types are wrong too.
This will be fixed by switching the action to Save File and back.

New update regarding the Always ask icon. Turns out, odd behaviour does in fact occur when using a Torrent client (I missed the fact that a Torrent file was registered in this image. My apologies for not noticing it sooner). Using Nightly 96.0a1 (2021-11-10), I followed these steps with the downloads pref enabled:

  1. Registered Torrent client BitTorrent as Windows 10 default app for Torrent files (same as comment 7)
  2. Downloaded a Torrent file
  3. Selected Always Open Similar Files on the downloaded Torrent file
  4. Opened Applications table in General settings to see content type and actions

After following these steps, I can confirm that the Always ask icon issue appears. Selecting Always ask will properly set the icon. However, I don't believe that actually resolves the issue. The (default) action that is supposed to appear when a default app is registered never appears. And in fact, I think that is the reason why the icon does not initially appear correct; the icon is meant for the default app.

Interestingly enough, the (default) option appears on the UnknownContentType window after selecting alwaysAsk and trying to download a Torrent file. If Do this automatically for files like this from now on is selected in this window while opening with the default app, the icon issue happens again in the Applications table.

Will look into this and see why this is happening.

A patch has recently been released for Bug 1738111. This should ideally resolve the issues found with the icon not appearing correctly.

After trying to reproduce the behaviour reported here, it seems the patch fixed issues concerning the incorrect alwaysAsk icon and default app for .Torrent files (the patch also addresses other file types like .zip, and I can confirm that I had no issues testing with .zip after the patch). So I will be closing this ticket.

As for the checkmark specific behaviour, this is currently being tracked at Bug 1740848.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: