I understand. I cannot reproduce that at the moment. But it was remarkable from the standpoint that the File Manager was trying to replace the Desktop folder instead of saving a link inside the Desktop folder, and that should never be the default action under any circumstances.
It sounds like the webpage was saved complete previously.
I think that's correct: in those tests which involved multiple attempts with both methods, I did not delete the previous items before trying again.
In that case, it sounds right to me that it would ask about replacing it, if it previously existed.
Agreed. But I never saw any prompts to replace a file. It always created duplicates. The one time that it deviated from this behavior, it tried to replace the Desktop folder for this user account, instead of replacing a file on the Desktop.
I have seen the file size represented incorrectly, so definitely suggest reporting it.
Do you think it's a Firefox issue or a File Manager issue? I don't have another distro to test it on right now.
Regarding second attempt: It is creating a link name with the same name, yes, but if you open a terminal and issue the command 'ls', you'll see that it names the actual filenames of the two links with unique names. If you were to create links (symbolic links) of regular files, it does give unique link names. Suggest reporting it.
I do understand that the file names would have to be different within the file system, even if they appear identical on the Desktop. But if you save from another application, the File Manager does not normally allow names which appear identical on the deskop. In that case it would prompt to rename or replace. So is this a bug in Firefox or the File Manager? Are there any distros where this works properly?
Regarding the replace message on second attempt: I can't tell when you are left-clicking on the shortcut, and can't get the replace message.
I cannot consistently reproduce this one, but will try to explain it better: I noticed that the second shortcut had the same title on the Desktop. In Firefox on Mac & Windows, you would either get a different name (appending 1,2,3, etc.) or it would prompt for replacement. So when I saw two shortcuts with the same identical name, I clicked on the first shortcut to select it. (But I now think a single right-click is what triggered this; sorry for the confusion.)
So I right-clicked once and the file replace dialog appeared instead of the context menu. In other words, it appears that a file replace dialog request was lodged in memory, but it was suppressed for some reason, and a duplicate shortcut was created without waiting for the request window to appear. When I right-clicked on the first shortcut, that suppressed 'conflict' dialog suddenly appeared, but it had no relevance in this context because the file with the duplicate name had already been created.
Notes:
-
The title on the desktop is "Link to..." but the replace dialog thinks the file is named "22"
-
There is no file on the Desktop with a visible title of "22"
(In terminal there is a file named "22" of 167kb but the file which represents the desktop shortcut is 263 bytes) -
The icon on the desktop is a blank page, but the replace dialog shows an icon with </>
(I think the correct icon for a shortcut is the favicon with an arrow overlay, or a generic URL icon with arrow overlay)
-
The original file size is 167 kb, and the replacement is
<null>because it was already saved without permission -
The properties dialog says the file size is "unknown" and the type is HTML (but the icon title on the desktop is "Link to..." and terminal says it is a ".desktop" file)
-
If I open a new File Manager window, I can see the contents, but cannot interact with the window while the file replace dialog is open (not sure if this is the expected behavior)
Even where I have a working shortcut, the properties say it's an HTML file, and the icon does not look like a shortcut. It's also missing the option to "open with" anything else (like text editor.) If I drag it into the text editor, it looks like a valid shortcut file. And the icon type specified is "mate-fs-bookmark." Is that icon type supposed to be represented by a blank page? Looks wrong to me.
Now if you have links or files left over from the attempt without shift-ctrl, that might be the cause.
Could be. So maybe the desktop shortcut feature needs to be fixed first, and maybe some of the other problems will go away. In any case, I did find something else worth noting here:
When I attempted to create a shortcut in the normal way, I saw a plus sign on the cursor momentarily. And then it changed to a question mark. On every subsequent attempt, it's always a question mark. So it looks like there is a filter driver or something which overrides the original file type specified by Firefox. If I could have dropped the shortcut on the Desktop during that moment when the cursor showed a big yellow plus sign, it would probably have created a valid shortcut without shift-CTRL. Would you agree that this sounds like a bug in the File Manager?
This might be happening every time you try to save a link, but maybe it happens too quickly to see, unless there are a bunch of pending file operations in the queue. Perhaps you could use a debugger to slow it down and verify this. But why would it save a shortcut correctly on the second attempt? That kind of implies we might be dealing with two separate issues here.
Regarding fourth attempt: I wouldn't expect a valid shortcut to consume 100kb, not by a long shot.
I think the confusion there was the fact that the properties dialog showed the properties of the HTML file instead of the shortcut. So if you have a valid shortcut on the desktop, but you also have an HTML copy, it seems like the link points to the local copy of the page. And when I launch that type of shortcut, in the lower panel the file manager says it is loading something like "22" (a local HTML file). But what is displayed in the browser is not the local copy; it is the live page. That makes no sense to me. The shortcut should not point to a raw HTML file on the desktop -- but if it does so for any reason, that should be what opens when you launch it.
About the valid information in the file properties, I did notice that there is a delay of generating the properties window but not what you saw.
In some cases the file properties had no valid information. In other cases there was a strange delay the first time you try to view the properties. So I can confirm those are two separate issues.
All of the working shorcuts had invalid information in the properties until I tried it without Shift-CTRL. It's really bizarre. But it does seem related to the same issue which causes the file replace dialog to be suppressed until you right-click on a Desktop shortcut.
I think the default for drag/drop should be a link, not an html page/file.
I have just found some documentation where Mozilla says that a link is the intended behavior. And while there still could be a bug in Firefox, I think there are some pretty serious bugs in the File Manager too.
I couldn't figure out your second attempt test of clicking on the first link. Can you duplicate it?
I did duplicate it once more by accident; I can now confirm that it was a single right click on the first shortcut. In order to reproduce this, I think you need to have at least two shortcuts. In the worst case, you may need to follow all of the steps that I posted earlier (where you create several shortcuts using both methods, allowing for any failure to create a valid shortcut.) I am not sure if it happens with both the Shift-CTRL method AND the normal method (where you get a valid shortcut on the second try.) Again this varies by web site in terms of reproducibility. Refer to the image above for an example of what to expect.
I'm neutral on the naming of links since the filenames are unique.
The standard on all other platforms is to append a number to duplicates, or prompt for replacement. In no case is it considered acceptable for multiple files on the desktop (of the same type) to display an identical name. And now I see that shortcuts do not appear in the File Manager. Can you confirm this? It's starting to look like things are so badly broken that it might be a long time before this gets fixed.