Open Bug 1772140 Opened 3 years ago Updated 10 months ago

bz2 extension appended to a .exe download

Categories

(Firefox :: Downloads Panel, defect, P3)

Firefox 102
x86_64
Windows 10
defect

Tracking

()

Tracking Status
firefox103 --- affected
firefox104 --- affected

People

(Reporter: thee.chicago.wolf, Unassigned)

References

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

Details

(Keywords: webcompat:platform-bug)

Attachments

(2 files)

STR:

  1. Navigate to https://ftp.mozilla.org/pub/firefox/candidates/102.0b2-candidates/build1/win64/en-US/
  2. Click on Firefox Setup 102.0b2.exe
  3. Download panels shows it downloading as Firefox Setup 102.0b2.exe.bz2

Seems to be new with 102.b1. Didn't see it with 101.x

Also had this happen on https://zoom.us/download when downloading the 64-bit 5.10.7 client.

Bug 1770683 was recently fixed and it may have solved this, could you please test again with the most recent version?

Flags: needinfo?(thee.chicago.wolf)
Attached image not-fixed.png

I just updated to 102.0b6. Still happening there.

Flags: needinfo?(thee.chicago.wolf)

It probably doesn't make any difference but in Settings > General > Application, bz2 Archive extension is set for Save File. Is there a way I can remove that extension from that Applications list so I can see what FF does when it doesn't exist? Just want to test a theory.

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

(In reply to Arthur K. [He/Him] from comment #4)

It probably doesn't make any difference but in Settings > General > Application, bz2 Archive extension is set for Save File. Is there a way I can remove that extension from that Applications list so I can see what FF does when it doesn't exist? Just want to test a theory.

Move the handlers.json file in your profile folder to some backup location. You can move it back once you finish testing the theory. If that does fix it, would you mind attaching that file (or at least the bz2-related parts if you're not comfortable sharing all of it) ?

(I'm also kind of hoping this is fixed in more recent 102 betas but I guess I can't count on it...)

Flags: needinfo?(thee.chicago.wolf)
Flags: needinfo?(mak)
Attached file handlers.json

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

(In reply to Arthur K. [He/Him] from comment #4)

It probably doesn't make any difference but in Settings > General > Application, bz2 Archive extension is set for Save File. Is there a way I can remove that extension from that Applications list so I can see what FF does when it doesn't exist? Just want to test a theory.

Move the handlers.json file in your profile folder to some backup location. You can move it back once you finish testing the theory. If that does fix it, would you mind attaching that file (or at least the bz2-related parts if you're not comfortable sharing all of it) ?

(I'm also kind of hoping this is fixed in more recent 102 betas but I guess I can't count on it...)

So, on my office PC, even after upgrading to 102 RC2, it still appends .bz2 to a download from the links I provided above. After removing handlers.json, all seems ok downloading from the above links. Attached my handlers.json for your review.

Flags: needinfo?(thee.chicago.wolf)

Somehow bz2 is associated to application/x-msdos-program in this handlers file...

(In reply to Marco Bonardo [:mak] from comment #8)

Somehow bz2 is associated to application/x-msdos-program in this handlers file...

I definitely didn't set it that way. I've downloaded .bz2 files for many, many moons without setting a handler for it.

Blocks: 1778322

Marco,

Do you think bug 1773907 is also related to this one and / or bug 1778322?

bug 1778322 is a more general tracking bug and it also includes this one.
While there may be some relation, bug 1773907 looks different, here we have handlers.json telling us something wrong.

See Also: → 1778160

This issue is still reproducible on Firefox 103.0b8(build ID: 20220712185923) and Nightly 104.0a1(build ID: 20220712093327) using the attached handlers.json. Tested on Windows 10 64-bits. macOS and Ubuntu are unaffected.

(In reply to Ardelean Oana from comment #12)

This issue is still reproducible on Firefox 103.0b8(build ID: 20220712185923) and Nightly 104.0a1(build ID: 20220712093327) using the attached handlers.json. Tested on Windows 10 64-bits. macOS and Ubuntu are unaffected.

Yes, the file somehow got borked and should only be used for testing. The solution was in comment 7 (read: remove the broken handlers.json, let FF re-create a new one).

TBH at this point I'm not sure what, if anything we could do here.

We won't be able to find out why the bz2 association with application/octet-stream happened - there's no history for the JSON file or "where things came from" information being tracked.

Is there some reasonable mechanism we could use to distinguish "good" associations from "bad" ones? We could exempt application/octet-stream, I guess - cf. bug 1659008, bug 1740841, bug 1738918... but otherwise, not sure there's much we can do. Marco, am I missing something? Otherwise I suggest we dupe this to one of those bugs - any fix there would likely excise entries like this anyway.

Flags: needinfo?(mak)

Neil, same question (comment #14).

Flags: needinfo?(enndeakin)

I'm fine with duping to one of the other bugs. I agree that it's basically impossible to know what screwed up this json file. I guess if I had to put a fine point on it, maybe it would be nice to see FF have a feature to "reset" the handlers.json file to default?

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

Is there some reasonable mechanism we could use to distinguish "good" associations from "bad" ones? We could exempt application/octet-stream, I guess - cf. bug 1659008, bug 1740841, bug 1738918... but otherwise, not sure there's much we can do. Marco, am I missing something? Otherwise I suggest we dupe this to one of those bugs - any fix there would likely excise entries like this anyway.

Management of octet-stream could indeed be improved, but in general I wonder if we should provide some UI to fix broken associations, though I'm not sure where it should be: in about:support or directly in the Preferences / Applications pane?
The only solution for the user shouldn't be to find and open the profile folder, and manually remove handlers.json.

Flags: needinfo?(mak)

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

TBH at this point I'm not sure what, if anything we could do here.

We won't be able to find out why the bz2 association with application/octet-stream happened - there's no history for the JSON file or "where things came from" information being tracked.

Is there some reasonable mechanism we could use to distinguish "good" associations from "bad" ones? We could exempt application/octet-stream, I guess - cf. bug 1659008, bug 1740841, bug 1738918... but otherwise, not sure there's much we can do. Marco, am I missing something? Otherwise I suggest we dupe this to one of those bugs - any fix there would likely excise entries like this anyway.

Hm, although re-reading the issue here isn't application/octet-stream, but application/x-msdos-program...

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

TBH at this point I'm not sure what, if anything we could do here.

We won't be able to find out why the bz2 association with application/octet-stream happened - there's no history for the JSON file or "where things came from" information being tracked.

Is there some reasonable mechanism we could use to distinguish "good" associations from "bad" ones?

I don't think we would be able to tell unless we provided a list we could consult to detect and/or fix bad associations perhaps when the user pressed a Reset/Fix button.

Flags: needinfo?(enndeakin)

It's complicate to find the right UI balance between "throw everything away" and "allow me to fix just this type" and making it non confusing for the non technical user. Thus we feel like probably the best solution would be to just trust the file extension like other browsers are doing, Bug 1750940.

Depends on: 1750940
Severity: -- → S3
Priority: -- → P3

I still got this on 103.0.2 while downloading Minecraft mods - .jar files which ended up as .jar.png. Removing the handlers.json file fixed it. I have also had the issue with downloading .exe files, but that went away with the update to 103.

The offending part appears to be this bit:

"extensions":["png","jar"],"handlers":[{"name":"firefox.exe","path":"C:\Program Files\Mozilla Firefox\firefox.exe"}]},"application/java-archive":{"action":0,"ask":false,"extensions":["jar"]},"text/plain":{"action":0,"ask":false,

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

Attachment

General

Created:
Updated:
Size: