When I try it the normal way (without Shift-CTRL)
First attempt: page saved as HTML document
Second attempt: page saved HTML document
Third attempt: asks if I want to replace the Desktop folder!!
The file save dialog also represents the file as "20 bytes" -- but the size on disk is 149 kb
note: the icon shown on the desktop is a blank page. On some other sites, the icon shown on the desktop has a symbol: </>
For those icons which display this symbol, the actual file type varies when I examine the properties, for example:
** unknown
** HTML document
** JPEG image
With the shift-CTRL method:
First attempt: an (apparently) valid shortcut is created
Second attempt: another shortcut is created with the exact same file name
left-click once on the first shortcut: it asks if I want to replace the file (after it has already saved a duplicate)
Third attempt: another shortcut is created with the same file name as the first two
(In properties dialog, file size is "unknown" for all)
Fourth attempt (this time without shift-CTRL) -- prompted to replace original file of 149 kb with a file of 20 bytes. (Is a valid shortcut expected to consume 100+ kb of disk space?)
When replacing the file is approved, the other shortcuts created with the Shift-CTRL method now have valid information in the properties dialog
This is just baffling.
taking into account @UnkleBonehead's comment about not many Linux users using shortcuts, I guess I could see how someone might want the default to be a file (save as webpage)
I don't think that he wants to use either one. But I don't believe that Mozilla intended for drag & drop to save as HTML, because you can already do that through the menu. Where shortcuts are concerned, there is no alternative method: it must be done through drag & drop, and that's how it works in Firefox on other platforms. But even if raw HTML was the intended behavior, drag & drop does not work the same way every time in Ubuntu Mate:
Sometimes it wants to save a shortcut, and sometimes it wants to save HTML. And sometimes it will tell you that it is doing one thing when it is really doing another. If you are monitoring the size of the files that it creates, and you verify whether the file on disk matches what the Firefox save-dialog says, and you start checking the properties on every file, these discrepancies will become much more obvious. Even in cases where the desktop icon remains consistent, the file type does not.
While the Shift-CTRL method seems to be the most usable workaround, even that is not 100% reliable -- but I have never seen a glitch on Mac or Windows. I am not trying to advocate for either of those platforms here, I am just trying to demonstrate that there does not appear to be a bug in Firefox on those platforms, and this information could be valuable to developers who are trying to isolate the cause of the problem in Linux. Sometimes it helps to have a point of reference. I don't think I have ever seen a bug which consistently produces such erratic and unpredictable results. But this should at least make it easier for developers to observe, because it does not take a long time for some kind of inconsistency to manifest.