Not sure why you expect it to remember the last used directory.
The documentation [1] unequivocally states the path is always relative to the default downloads directory.
It was always this way since chrome.downloads API was implemented in Chrome 31 almost six years ago.

   filename	
   A file path relative to the Downloads directory to contain the downloaded file, possibly containing subdirectories.

[1]: https://developer.chrome.com/extensions/downloads#method-download

To be honest, I didn’t expect this either :D

However, Chrome does remember the last chosen directory if no filename is specified to downloads.download with Save As. This recent directory can be a directory outside of the default downloads directory, e.g., if you save to Desktop or a documents folder. It seems that lots of people using an extension I built really like this and it’s maybe the best way to quickly save files somewhere other than inside or underneath the default downloads directory.

I also tested this on Windows 7 with Chrome 49 and it’s the same as my Mac example.

Given how Save As works without specifying a filename, my intuition would have been that a filename without any slashes in it would function the same as Save As without specifying any filename and when it does have slashes, e.g., "./foo.txt" or "my-extension/foo.txt", then it defaults to underneath the default downloads directory.

I feel like that’d be better functionality, but it could lead to unexpected results for existing apps. I don’t see a good fix to this other than (a) changing the functionality to match what I outlined in the previous paragraph or (b) adding an additional boolean option like `allowRecent`. B feels sloppy. A feels more elegant, but could annoy other people?

As a workaround, I realized I could save a file to the HTML5 file system with my desired filename, then download that without specifying a filename :O

The additional parameter is actually a plausible idea while changing the default behavior is definitely not for two reasons: it'll break all/many/most existing extensions and it's not how APIs work in general - user actions should not change the outcome of the same-parameter invocation.

Anyway, you should be able to implement what you want with the current API quite easily: chrome.downloads.download returns an ID of the DownloadItem which you can query in chrome.downloads.search which returns an array of matching items (only one here) so you can get the full local path in filename property, save it, and use in subsequent downloads.

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #66.0.3359.139 and latest canary #68.0.3423.2.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

@woxxom - I don’t follow your example of using the DownloadItem. I am looking for the saveAs dialog to both accept my custom filename and yield the most recent directory a user saved something to (which can be outside of the default downloads directory, e.g., /Users/foo/Desktop/ instead of /Users/foo/Downloads/). I’m not seeing how that can be achieved with the current APIs or DownloadItems and downloads.download.search?

The suggested path can't be outside of the default downloads directory. This is a security restriction, which is unlikely to ever change.

Printing remembers; Saving remembers; but downloading is odd and doesn't remember.  Download behaviour is most unhelpful since you often want to download several things to the same folder, and it's a pain to have to keep navigating there.  Need another download option to choose recent download folder.  Make it a new command/API if you don't want to change the old one.  Also, would be good to remember last download location per website, like you have other settings that are remembered by website.