User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140127194636 Steps to reproduce: download the file (not 'save as ...') Actual results: FF 27 ignore download direction setting (even edit about:config) and compulsory save file to Windows default download [C:\Users\%USERPROFILE%\Downloads] directory

Was the download destination you told Firefox to use the root of the drive (e.g. "C:\" or "E:\" ) ?

no, C:\Users\hong620\Downloads not on root. it's apear right after 26.x -> 27.0 update. 'save as ...' function is okay. i'll reset some of involved config string value about browser.download but still malfunction.

Having same issue since V26->V27 upgrade. Downloads default to C:\Users\%USERPROFILE%\Downloads instead of specified drive. Reset the download location several times but still happens. I do have the directory set to the root level but I've had it set that way since Firefox 1 and it's always worked.

Same issue in Mac OS X also.

still issue in 27.0.1

Same issue in 27.0.1 on Win8.1 but just when download directory is set up into the root for example D: When its changed into the directory, then its working fine.

(In reply to Radek from comment #6) > Same issue in 27.0.1 on Win8.1 but just when download directory is set up > into the root for example D: > When its changed into the directory, then its working fine. i'm testing on drives root (ex: C: D: E: F: G: H: I:) but mine is not save to each roots. still saved in [C:\Users\%USERPROFILE%\Downloads] it's strange..

Yep issue continues with v27.0.1 Problem exists only when setting the downloads directory to the root of a drive. If this is by design I could understand not saving to root level of the boot drive but other drives I don't understand.

(In reply to hong620 from comment #2) > no, C:\Users\hong620\Downloads > not on root. > > it's apear right after 26.x -> 27.0 update. > > 'save as ...' function is okay. > > i'll reset some of involved config string value about browser.download but > still malfunction. My question was about where you *wanted* the file to be saved, not where it *was* eventually saved. Per the later comments, this is a dupe of bug 958899