dragging the favicon from the location bar fails to create a desktop/shortcut file in the target folder

NEW
Unassigned

Status

()

Firefox
Location Bar
7 years ago
2 years ago

People

(Reporter: Forest, Unassigned)

Tracking

({regression})

3.6 Branch
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

In previous versions of Firefox, I could drag the favicon from the left side of the address bar to a file manager window, and it would create a .desktop shortcut in the right folder.  This no longer works.

Reproducible: Always

Steps to Reproduce:
1. Open a folder in Thunar (or any GUI file manager).
2. Open a web page in Firefox.
3. Drag the favicon from the address bar and drop it on the folder window.
Actual Results:  
The drop is ignored.

Expected Results:  
A .desktop shortcut file should have been created in the target folder.

This worked fine in Firefox 3.5.  Upgrading to 3.6 seems to have broken it.

I was unable to find an existing bug report for this particular behavior with the favicon, but I did find bug 478070 which concerns dragging the address bar text.
(Reporter)

Updated

7 years ago
Summary: dragging favicon to a thunar folder fails to create a desktop/shortcut file → dragging the favicon from the location bar fails to create a desktop/shortcut file in the target folder

Comment 1

7 years ago
Works fine for me using Firefox 3.6.3 (Mozilla build) on Kubuntu 10.04 with Dolphin 1.4 in KDE SC 4.4.2.

You could try Firefox safe mode or a new profile to see if it's an addon or setting that's interfering somehow:
http://support.mozilla.com/en-US/kb/Safe+Mode
http://support.mozilla.com/en-US/kb/Managing+Profiles

Could also be a bug in Ubuntu's build or something GNOME related.
Version: unspecified → 3.6 Branch
(Reporter)

Comment 2

7 years ago
I tried it with a fresh profile, and it still didn't work.  Perhaps this feature was broken only for certain file managers?  I'm using Thunar from Xfce.  Like I said, it worked fine in previous versions of Firefox.
(Reporter)

Comment 3

6 years ago
I eventually found a workaround for Firefox 3.6: highlight the URL in the address bar, then drag the highlighted URL to the target folder.  However, that workaround no longer works in Firefox 5.0.

I am now using XUbuntu Natty.  This is still a problem, though the behavior is different in Firefox 5.  It differs from site to site.

Dragging the http://www.amazon.com/, http://www.mozilla.org/, or http://www.google.com/ favicon to a folder yields an error dialog:
"Failed to launch operation. Invalid argument."

Dragging the http://www.iana.org/domains/example/ favicon to a folder creates a file in that folder that contains html, presumably copied from the web site.

This is with a new profile on a new installation of XUbuntu Natty.
(Reporter)

Comment 4

6 years ago
Problem still exists with Firefox 6.0.

Updated

6 years ago
Duplicate of this bug: 589722
there may be a code relation with bug 625063
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this problem on Windows as well and have a patch that fixes it. I will upload one shortly.
Assignee: nobody → jwein
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: x86 → All
Sorry, I spoke too soon. The patch that I have fixes dragging the URL, not the favicon.
Assignee: jwein → nobody
Status: ASSIGNED → NEW
OS: All → Linux
Hardware: All → x86

Comment 9

4 years ago
I installed a fresh Fedora 18 system and updated.  Using Gnome everything worked as expected.  I then installed XFCE and experienced this problem.

Under Gnome: Dragging site icon to files created a .desktop link which could then be dragged into a browser to load a URL.

Under XFCE:  Dragging site icon to files creates a .html and is spurious, as ctrl-u displays HTML and allows saving of html, given the common usage and expectation is creation of a link file (.desktop).

Is this a problem with Firefox?  Is anyone working it?  From the previous post in 2012 it looks like it was assigned back to "nobody."
(Reporter)

Comment 10

2 years ago
Just so nobody thinks this bug is stale:
Problem still exists in Firefox 41.0.2.

Updated

2 years ago
Keywords: regression
You need to log in before you can comment on or make changes to this bug.