See site, to reproduce the bug: - Open site, do "Save Page As.." - Use the name as suggested and try to save Expected result: - The page gets saved Actual result: - The page doesn't get saved, I see an "This download has been blocked by your Security Zone Policy - kothlah.org" error in the download manager. When I save the page as "a.htm", then the saving just works fine.
Martjin, I'm not able to reproduce - saving out is working here. Can you hook me up with a specific uri where this happens?
ahh, never mind. I can reproduce.
Regression is from bug 416683; I traced the regression range down to 2008-03-21 (works) to 2008-03-22 (fails)
Updating the summary, this also affects downloads. Also added the bit about long file names to the summary. Asking for blocking: in case of downloads you just can't download the file (the file name is determined automatically). I'm getting this once or twice a week (in gmail, downloading attachments).
Microsoft's documentation on SetLocalPath is pretty spotty. Would the usual mechanism of prepending "\\?\" to override the old path length limits work for SetLocalPath? (they usually mention that in their docs, but no mention of it here...)
I think we should be using SetFileName for files that aren't local yet, not SetLocalPath. There's a note about this on MSDN under SetFileName. I'd have a patch posted already but I can't seem to figure out a way to get from an nsIURI -> leaf name without trimming it out manually.
Is there a possibility of this problem cropping up for the AV scan as well? http://mxr.mozilla.org/mozilla/source/toolkit/components/downloads/src/nsDownloadScanner.cpp#493
> Is there a possibility of this problem cropping up for the AV scan as well? No because at that point, the local path is valid. I've tested this patch on all the examples given and it appears to have fixed the problem. Building on try server now, I'll post the try build link once it's complete in case anyone wants to take it for a spin.
Comment on attachment 318175 [details] [diff] [review] check policy patch v.1 Looks good to me
(In reply to comment #12) > Try server builds - > https://build.mozilla.org/tryserver-builds/2008-04-28_09:firstname.lastname@example.org/ Tested on Windows Vista, and I verified that it fixed the file-saving problem (haven't had much time yet to do regression testing, though).
I wonder if sdwilsh is doing reviews, he might be involved in school. If he doesn't chime in here sometime tomorrow I'll switch to a different reviewer.
Confirm - saving ok.
Comment on attachment 318175 [details] [diff] [review] check policy patch v.1 r=sdwilsh
Can we do any testing here? I know this is a blocker, but still.
Comment on attachment 318175 [details] [diff] [review] check policy patch v.1 a1.9=beltzner
(In reply to comment #18) > Can we do any testing here? I know this is a blocker, but still. Not in any automated way - you need to change system settings. We can get litmus tests though. Unless this was caused by a long filename, then *maybe*. It's my understanding that this bug wasn't caused by a long filename though.
(In reply to comment #20) > (In reply to comment #18) > > Can we do any testing here? I know this is a blocker, but still. > Not in any automated way - you need to change system settings. We can get > litmus tests though. > > Unless this was caused by a long filename, then *maybe*. It's my understanding > that this bug wasn't caused by a long filename though. Shawn: https://bugzilla.mozilla.org/show_bug.cgi?id=430566#c7 implicated path-length limits, which means this might be testable via long filenames, no? Regardless, I've got a Litmus case up at https://litmus.mozilla.org/show_test.cgi?id=5309 (I might be/probably am wrong; sorry in advance; it'd just be nice to have this automated, since in-the-wild-content changes often.)
This definitely wasn't caused by long filenames. The exact cause though is unknown since the problem showed up in a black box api call with little documentation. My guess is, the call was ignoring invalid file paths that were less than MAX_PATH, and failing on ones that were. We now use just the filename setting so the code path is very different.
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre. I verified by using the test URL.