Closed Bug 430566 Opened 12 years ago Closed 12 years ago

Saving web page/some downloads fail with "blocked by your Security Zone Policy" (caused by long file name?)

Categories

(Toolkit :: Downloads API, defect, major)

x86
Windows Vista
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: martijn.martijn, Assigned: jimm)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

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.
Assignee: nobody → jmathies
Regression is from bug 416683; I traced the regression range down to 2008-03-21 (works) to 2008-03-22 (fails)
Flags: in-testsuite?
Flags: in-litmus?
Duplicate of this bug: 430964
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).
Severity: normal → major
Flags: blocking-firefox3?
Keywords: regression
Summary: Saving web page doesn't work, getting Policy error → Saving web page/some downloads fail with "blocked by your Security Zone Policy" (caused by long file name?)
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.
Flags: blocking-firefox3? → blocking-firefox3+
Attachment #318175 - Flags: review?(tellrob)
Comment on attachment 318175 [details] [diff] [review]
check policy patch v.1

Looks good to me
Attachment #318175 - Flags: review?(tellrob) → review+
Attachment #318175 - Flags: superreview?(sdwilsh)
Whiteboard: [has patch][needs review sdwilsh]
(In reply to comment #12)
> Try server builds - 
> https://build.mozilla.org/tryserver-builds/2008-04-28_09:54-jmathies@mozilla.com-bug430566v1/

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.
Whiteboard: [has patch][needs review sdwilsh] → [has patch][needs review sdwilsh!]
Comment on attachment 318175 [details] [diff] [review]
check policy patch v.1

r=sdwilsh
Attachment #318175 - Flags: superreview?(sdwilsh)
Attachment #318175 - Flags: review+
Attachment #318175 - Flags: approval1.9?
Whiteboard: [has patch][needs review sdwilsh!] → [has patch][has review][needs approval]
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
Attachment #318175 - Flags: approval1.9? → approval1.9+
Whiteboard: [has patch][has review][needs approval] → [needs landing]
Whiteboard: [needs landing] → [has patch][has reviews][needs landing]
Whiteboard: [has patch][has reviews][needs landing] → [needs landing]
Keywords: checkin-needed
Whiteboard: [needs landing] → [has patch][has reviews][has approval]
(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.
Flags: in-testsuite? → in-testsuite-
(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.)
Flags: in-litmus? → in-litmus+
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.
mozilla/toolkit/components/downloads/src/nsDownloadScanner.cpp 	1.19 
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews][has approval]
Target Milestone: --- → Firefox 3
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.
Status: RESOLVED → VERIFIED
Duplicate of this bug: 434223
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.