Download locations not sticking

[asterisk]

This is an extreme annoyance that has bitten me over the last few days. I can't recall if Firefox also had this behaviour, so it may be an old code algorithm that's never been fixed. My working assumption is that download locations are remembered according to the document type. Certainly, when I download a .EXE file PM always suggests the location I've always used for downloadable software, regardless of where I've saved media subsequently. However, I've been visiting a couple of blogs to download images recently, all JPG, and found that the download suggestions are not working logically at all.

I (like most people I assume) prefer to organise content into folders, so when I start a new media folder I browse to that new download location and save the first image. I would EXPECT that the next image I download should be suggested to go into that same folder. It's another JPG, and I've just updated the last-saved-to location for JPGs. NO other suggestion would be appropriate, especially when the image is of the same type, name structure, and from the same webpage. What ALWAYS happens, though, is that for the second and third subsequent downloads I get another suggestion instead from a download location that I used recently, although not always the last one I used (this is the most frequent suggestion though). I have to click through the explorer tree to find where I wanted it, often quite a time-consuming browse in a complex tree, to save. It will always take at least three goes at this, rechoosing the correct folder, before the new download location "sticks" as a save suggestion. Occasionally, even after "sticking" it will randomly suggest a previously used location, which is a total PITA if you're not concentrating and assuming all the images are going where you've explicitly asked them to.

I cannot understand how this algorithm could be going wrong. There can only be a list of base filetypes and last-saved-to locations (presumably in the registry). Once the last-saved-to location for a particular filetype is updated, why on earth would there be ANY record of a previous location used as a suggestion? Based on what, in any case? The filename, or page source? Second-guessing the user is just creating confusion. If there is some intended behaviour here I cannot see what it could possibly be, and how it is of benefit in the most likely scenario. Ditching/ignoring ALL previous download locations for a filetype after you've set/selected a new location should surely be a massive code simplification as well as a time-saver for users.

There's another wrinkle in this - if I change the name of the folder I've just been downloading to, or move/delete it, it no longer exists as a location match when I try to save the next image, so the suggestion ALWAYS falls back to what seems for me to be set as the "base" location, possibly the first one in some list, which for me is the location for .EXE files. Since for me this is on a different drive the number of clicks required to reset the location to a media structure on another hard drive is considerable. And remember, this new location doesn't "stick" until you've repeated this infuriating "Yes, I REALLY want it here" rigmarole at least three times. I'd STRONGLY suggest that a better algorithm would not be to fall back to the location of a totally unrelated filetype, but to to walk back up the folder tree from the missing location until a valid location is found, which will be more likely closer to the intended location for an identical filetype.

[Moonchild]

Download locations are determined and stored not by file type, but by host.

So, if you download something from site1.com, it will remember the last saved location for the next time you download from site1.com. in general, this is more useful than just lumping all files with the same extension together.

[asterisk]

But I'm downloading consecutively from the same website/blog. So this explanation doesn't make sense UNLESS the "host" that you are matching is so fine-grained and explicit a match that it's practically useless in normal usage.

In my case it's blogspot.com, and the images are served from a complex (possibly changing) folder structure in a multitude of https subdomains such as 2.bp.blogspot.com which suggests a flaw in the thinking behind this algorithm. If the host match is just blogspot.com regardless of subdomain then I shouldn't be having this difficulty. Your "in general this is more useful" isn't working at all for me because of poor matching. In fact, it's a nightmare in this situation, and I don't see this as a corner-case in an age of blogs all using similar resource URL obfuscation.

It is also leading to user misunderstanding. The fact that by default for me downloading installer .EXE files goes to an expected location has led me to believe that's a particular association with .EXE files, not just the first match I may once have made which is now being used as a super default for ALL downloads that aren't host-matched. That's NOT useful if that location is a poor default for other filetypes. I'd suggest that there should be user configuration of this feature which could allow it to switch from host-based to filetype-based matching if it works better for users.

And I have to say that storing a short list of global filetypes rather than a potentially huge speculative database of historical host matches (most of which will be highly transient) is WAY more RAM and code-efficient, never mind the CPU cost of searching that database on every file save. Frankly I'm shocked - it's that sort of memory bloat and speed inefficiency that I thought PaleMoon was trying to work to eliminate.

[Moonchild]

A host is a host, not a domain.
So, if a website decides to serve files/media from multiple hosts, you'll have separate entries for it.
Before you go and say "but it must be done by domain only", consider domains that use subdomains to indicate individual websites or interests, e.g. all subdomains of wordpress.com or blogger.com, where you don't want a single location stored for the umbrella domain.

As for ram/cpu requirements -- negligible; it's done with database lookups.

[asterisk]

OK, it may be more workable for some situations. But can you admit that it's not helpful in the (probably common) situation I'm experiencing? We're talking serious mouse-bashing to navigate around saving files because there's no way to over-ride or set the depth of the host-matching. Your job surely is to make the use of the browser easy for users globally, not punish some of us for visiting sites which don't conform to your personal idea of good file-structure.

A way for users to prefer file-type-matching or to set the host-match subdomain level at the very least would be helpful. Please consider it.

[asterisk]

Here's a slightly related bug associated with image views. If I click through a thumbnail to the full-size image, so the browser isn't displaying a webpage but ONLY the image, and then right-click that to "View Image Info", I get a somewhat useless pop-up without a further unnecessary click. The "tabs" there are General, Permissions, Security and Headers, but NONE are selected, so the pop-up is effectively empty on opening, with an empty table containing headers for Address and Type. It takes an extra click on the General tab selector at the top to get what should be the default opening state for this pop-up, showing basic info like filename, dimensions and size.

As a suggestion, this info is partially duplicated in the browser window title, giving the filename and image dimensions, but it would also be useful to put the image size in KB there as well to avoid having to right-click just for this basic info.

[asterisk]

Further info on above bug - the issue is the lack of the "Media" tab in this image info dialog. The pop-up is attempting to open this (I think correctly) by default, but it is not being populated and the tab header is not appearing, so some load code is presumably being bypassed. This works for me correctly on pages with even minimal HTML framing the image, just not where the image is all that's being sent to the browser.