As part of testing for the Downloads panel improvements a thorough extension testing has been performed: complete list of extensions tested here: testrail_link

The following types were found to be added as a generic "Firefox HTML document" (windows) , "HyperText Markup Language" (mac), when using "Always open Similar files" which we believe it's not quite correct:

A. Windows 10 (testing complete)

.cfm (href from localfile html )
.key ( https://github.com/filestar/File-Type-Sample-Repository/tree/master/key )
.oft (https://github.com/Road-hog123/British-Road-Detailing-Pack-2/tree/master/OMSI%202/Fonts)
.pst (https://github.com/tghanem/PST/tree/master/pst/pst.tests/Resources)
.vcf (https://github.com/elimuinformatics/vcf2fhir/tree/master/vcf2fhir/test)
.cgi (https://github.com/miyagawa/CGI-Compile/find/master)
.dmp (https://github.com/oracle/db-sample-schemas/tree/main/order_entry)

B. MAC (testing complete)

.cfm (href from localfile html)
.key ( https://github.com/filestar/File-Type-Sample-Repository/tree/master/key )
.oft (https://github.com/Road-hog123/British-Road-Detailing-Pack-2/tree/master/OMSI%202/Fonts)
.vcf (https://github.com/elimuinformatics/vcf2fhir/tree/master/vcf2fhir/test)
.cgi (https://github.com/miyagawa/CGI-Compile/find/master)
.dmp (https://github.com/oracle/db-sample-schemas/tree/main/order_entry)

C. Ubuntu (testing complete)

.cfm (href from localfile html)
.key ( https://github.com/filestar/File-Type-Sample-Repository/tree/master/key )
.oft (https://github.com/Road-hog123/British-Road-Detailing-Pack-2/tree/master/OMSI%202/Fonts)
.vcf (https://github.com/elimuinformatics/vcf2fhir/tree/master/vcf2fhir/test)
.cgi (https://github.com/miyagawa/CGI-Compile/find/master)
.dmp (https://github.com/oracle/db-sample-schemas/tree/main/order_entry)

Note:

1. Additionally, all the above content types stack with eachother and the auto-open doesn't work in this case.
2. These cases are most likely also highly dependent on the default association file types aswell, so it might be the case that it would work properly having the right software installed ?!?

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

As part of testing for the Downloads panel improvements a thorough extension testing has been performed: complete list of extensions tested here: testrail_link

The following types were found to be added as a generic "Firefox HTML document", which we believe it's not quite correct:

I'm assuming you're talking about how they show up in Firefox's preferences/settings, when using "always open similar files"? But it's not clear from comment 0...

Like in bug 1750979, the problem is likely related to the mimetype the server sends.

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

I'm assuming you're talking about how they show up in Firefox's preferences/settings, when using "always open similar files"? But it's not clear from comment 0...
Like in bug 1750979, the problem is likely related to the mimetype the server sends.

Yes, I'm reffering to the fact that all of the listed examples above are added under the same content type "Firefox HTML document" and the default action would be "Open with Firefox", but that doesn't actually do an auto-open on download which is fine for Save link as. see also https://bugzilla.mozilla.org/show_bug.cgi?id=1750990#c3 . Interesting enough, if I manually open the file from download pannel, it works calling the right app. (for example in the .vcf case (https://github.com/elimuinformatics/vcf2fhir/tree/master/vcf2fhir/test ), it will open with People which is the default app. in my Windows) - guessing Firefox will pass it to the OS ?

On an older build, if you get the dialog asking what to do with the file, if you click "save to disk" and then tick the "always do this for [files]" checkbox before accepting the dialog, do we create the same item in the preference? I suspect so, but it would be good to check.

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

On an older build, if you get the dialog asking what to do with the file, if you click "save to disk" and then tick the "always do this for [files]" checkbox before accepting the dialog, do we create the same item in the preference? I suspect so, but it would be good to check.

That is a bit of a trick question, because on old (or improvemnt disabled - tested with 91.0.5 ESR) we don't add handler unless "always do this for [files]", which assumes the OS will give options, but:

• on Windows, for unknown OS handler files, you don't have it
• On Mac, if you force it, it will lead to bug 1752164

So, to answer the question, we don't create the same specific handler item with the improvements off because we were never in this situation. With the improvements on, we are now in the situation in which we want to add a handler that has no OS action yet.

Later edit:
An indirect way to observe the handling on improvements disabled, in a way the same, is do do "save as" and to observe the type of the file that we are saving as: saving a file.tmp file would get the Firefox save state that it will save a Text Document (*.tmp). See also https://bugzilla.mozilla.org/show_bug.cgi?id=1750990#c3

As I gave this more thought and testing time, seems to me we're mostly doing this on Save file as, which behaves a bit different than the direct download. Probably this issue and bug 1750990 can be duped under a new one which IMO should align to download, when saving file as and adding content type handler from such a file, without taking in account what the sender might tells us it is, especially in the case in which we neither we or the OS do know what shall be done with the extension. I find it highly confusing that depending on the source and option, I might get a different handling behaviour for the same type of file.
In my (narrow maybe) view as long as we end up saving/downloadding a file.ext, the .ext should be the source of truth in what handler type we might add.
@Gijs, thoughts?

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

In my (narrow maybe) view as long as we end up saving/downloadding a file.ext, the .ext should be the source of truth in what handler type we might add.
@Gijs, thoughts?

I think this is reasonable but it's not something we can fix in a straightforward manner, unfortunately. :-(