If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in mozilla1.9

Status

()

Toolkit
Downloads API
--
major
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: jimm)

Tracking

({regression})

Trunk
mozilla1.9
x86
Windows Vista
regression
Points:
---
Bug Flags:
blocking1.9 +
in-testsuite -
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
Martjin, I'm not able to reproduce - saving out is working here. Can you hook me up with a specific uri where this happens?
(Assignee)

Comment 2

10 years ago
ahh, never mind. I can reproduce.
(Assignee)

Updated

10 years ago
Assignee: nobody → jmathies
Regression is from bug 416683; I traced the regression range down to 2008-03-21 (works) to 2008-03-22 (fails)
Blocks: 416683
Duplicate of this bug: 430849
Flags: in-testsuite?
Flags: in-litmus?

Updated

10 years ago
Duplicate of this bug: 430964

Comment 6

10 years ago
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?)

Comment 7

10 years ago
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...)
(Assignee)

Comment 8

10 years ago
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.
(Assignee)

Comment 9

10 years ago
Created attachment 318175 [details] [diff] [review]
check policy patch v.1

Comment 10

10 years ago
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
(Assignee)

Comment 11

10 years ago
> 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+
(Assignee)

Comment 12

10 years ago
Try server builds - 
https://build.mozilla.org/tryserver-builds/2008-04-28_09:54-jmathies@mozilla.com-bug430566v1/
(Assignee)

Updated

10 years ago
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+
(Assignee)

Updated

10 years ago
Attachment #318175 - Flags: superreview?(sdwilsh)

Updated

10 years ago
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).
(Assignee)

Comment 15

10 years ago
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.

Comment 16

10 years ago
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?

Updated

10 years ago
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]

Updated

10 years ago
Whiteboard: [needs landing] → [has patch][has reviews][needs landing]
Whiteboard: [has patch][has reviews][needs landing] → [needs landing]

Updated

10 years ago
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+
(Assignee)

Comment 22

10 years ago
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
Last Resolved: 10 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: 426050

Updated

10 years ago
Duplicate of this bug: 434223
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.