1418073 - Drag & Drop for images to desktop strips file extensions

Status: RESOLVED DUPLICATE of bug 1389836

(Firefox :: File Handling, defect, P1)

Description

[Christopher Curzio]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

1. Go to any page with an image, or any direct image URL. (Good example: https://www.cl.cam.ac.uk/coffee/xvcoffee.jpeg)
2. Drag the image from the browser to your OS desktop. 


Actual results:

The file was saved to the desktop, but without any kind of file extension. This happens everywhere with every kind of image. 


Expected results:

Firefox should save the file including the appropriate file extension.

Comment 2

[Neil Deakin]

I can reproduce this.

I can see a special handler for JPEG in Preferences->General->Applications. There doesn't seem to be a way to remove it.

Deleting handlers.json from the profile directory fixes the issue. I assume one can just delete the jpeg parts from handlers.json.

Comment 4

[Tortinello]

My bug is with PNG images and not with JPEG.. strange

Thanks Neil! I solved my bug by deliting handlers.json file from my profile :)

Comment 5

[Jeff Thompson]

I have this bug with my system. Intel MacMini (late 2012) running OS High Sierra.  when browsing with firefox 57 if I drag a jpeg image to my desktop it saves as a TextEdit app instead of a .jpg

if the option to download is available it saves it correctly.

Only have this issue w/firefox and not any of my other browsers (safari / opera.. )

Comment 6

[Flore Allemandou [:flore]]

Did you try the fix proposed in Comment #2 ? Delete handlers.json

Comment 7

[Jeff Thompson]

(In reply to Flore Allemandou [:flore] from comment #6)
> Did you try the fix proposed in Comment #2 ? Delete handlers.json

I have searched for handlers.json in my system pref and finder pref and can not find it.

Comment 8

[Flore Allemandou [:flore]]

It is located in your firefox profile: https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data

Comment 9

[Jeff Thompson]

(In reply to Flore Allemandou [:flore] from comment #8)
> It is located in your firefox profile:
> https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data

Done,  and yes now it works.  Thank you very much!!!

Comment 10

[u595769]

Interesting. But if it’s such a simple adjustment, why then wasn’t it fixed in the latest release or in the next? Users shouldn’t be bothered with diving into code. This bug has an unbelievably low priority for something that's so noticable.

Comment 11

[Flore Allemandou [:flore]]

(In reply to webber59 from comment #10)
> Interesting. But if it’s such a simple adjustment, why then wasn’t it fixed
> in the latest release or in the next? Users shouldn’t be bothered with
> diving into code. This bug has an unbelievably low priority for something
> that's so noticable.

It does not appear with a new profile, so it's not really a bug from Firefox, rather a problem with a profile that has been used for a long time and needs some fix.
Like you buy a new bike, use it every day and after 6 months there are a few things that loosened and need a small fix. You fix them, but the manufacturer did what they could to prevent big problems, but not small issues due to usage.

Comment 12

[u595769]

(In reply to Flore Allemandou [:flore] from comment #11)
> (In reply to webber59 from comment #10)
> > Interesting. But if it’s such a simple adjustment, why then wasn’t it fixed
> > in the latest release or in the next? Users shouldn’t be bothered with
> > diving into code. This bug has an unbelievably low priority for something
> > that's so noticable.
> 
> It does not appear with a new profile, so it's not really a bug from
> Firefox, rather a problem with a profile that has been used for a long time
> and needs some fix.
> Like you buy a new bike, use it every day and after 6 months there are a few
> things that loosened and need a small fix. You fix them, but the
> manufacturer did what they could to prevent big problems, but not small
> issues due to usage.


Okay, I understand now, thanks for explaining :-)

If I sounded a bit annoyed, it’s because it’s often hard to understand for a layman like me how priorities are determined. Thanks again for this relevant answer. If still necessary I will also refer to this solution on the support forum where a question was asked about this bug.

Comment 13

[Flore Allemandou [:flore]]

No problem, and yes feel free to share this solution on the support forums, it will help others, surely.
Maybe there is something developers can do to prevent this from happening, so the bug is still open. But it's not affecting all mac users, so it's a low priority bug (IF something can be done anyway)

Comment 14

[u595769]

Sorry, two more questions:

1. If I delete the handlers.json file, won’t that affect other file formats as well? Most of them disappear in the Preferences > Applications section. Or do they rebuild themselves over time?

2. Instead I’ve tried this:
- open the handlers.json file in textedit
- deleted the following part in it:

,"image/jpeg":{"action":2,"extensions":["jpg","jpeg","jpe"],"ask":true}

- keep this changed file in the same location.
That worked as well

Comment 15

[Jeff Thompson]

one more questions in regards to this.  yesterday I followed the steps of deleting handlers.jon  even emptied the trash.  this morning after booting up my system and starting a new session on firefox.  same issue with dragging jpegs and yes the handlers.jon is back in my profile.

Do I have to now do this everytime I open firefox?

Comment 16

[2761c4f2]

https://support.mozilla.org/en-US/questions/1178764
https://support.mozilla.org/en-US/questions/1177461
https://support.mozilla.org/en-US/questions/1189481

seems to be a correlation, I have the same problem too and I don't have this 
behaviour with Chrome!

Comment 17

[Neil Deakin]

Several reports suggest this might have started in 56 and applies to Mac only.

Comment 18

[Christopher Curzio]

Deleting handlers.json is not a fix. It works for a little while (probably until you restart the browser), then the behavior comes right back.

Comment 19

[u595769]

(In reply to ccurzio from comment #18)
> Deleting handlers.json is not a fix. It works for a little while (probably
> until you restart the browser), then the behavior comes right back.

What worked for me was (see comment 14): 
- close Firefox
- copy the handlers.json file to the desktop
- change the code as described in comment 14
- copy it back to the old location
- restart Firefox

I’ve done this 2 days ago, and this fix still works.
Also this way all other handlers are still in place as they where before the change.
Don’t know what happens though if Firefox is updated (hasn’t happened yet).

Comment 21

[Marcelo Jaccoud Amaral]

These workarounds do not correct the problem, they just prevent the faulty code from being called by the handler. Thus, there is no solution at all. The handling of JPEG images should not be different from the handling of PNG, SVG or any other drag-and-dropable resource. I can drag links (an extension .webloc is provided), text (.texClipping) etc. But if the URL doesn't have an explicit extension, draging the image fails even with the above cited workaround, because the necessary .jpeg extension will not generated for the image/jpeg MIME type, since the handler is not called. 
We need to fix the handler instead of avoiding to call it.

Comment 22

[Marcelo Jaccoud Amaral]

Also, it is not caused by old profiles. I have tested with a brand new instalation of Firefox on Sierra, and the bug appears right after updating from 56 to 57. Something broke from 56 to 57, and it was not the handlers listing file, but the handler routine itself.

Comment 23

[:Paolo Amadini]

This is very likely the same as bug 1389836, which should be already fixed in Firefox Beta.

This bug didn't occur if any legacy add-ons that disabled the multi-process mode were installed, thus some people may have seen it only starting from Firefox 57, when legacy add-ons were disabled and multi-process was enabled.