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

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Jim Mathies [:jimm]]

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

Comment 2

[Jim Mathies [:jimm]]

ahh, never mind. I can reproduce.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Regression is from bug 416683; I traced the regression range down to 2008-03-21 (works) to 2008-03-22 (fails)

Comment 6

[Nickolay_Ponomarev]

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).

Comment 7

[Kai Liu]

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...)

Comment 8

[Jim Mathies [:jimm]]

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.

Comment 9

[Jim Mathies [:jimm]]

Attachment: check policy patch v.1

Comment 10

[Kai Liu]

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

Comment 11

[Jim Mathies [:jimm]]

> 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 12

[Jim Mathies [:jimm]]

Try server builds - 
https://build.mozilla.org/tryserver-builds/2008-04-28_09:[e-mail]-bug430566v1/

Comment 13

[Rob Arnold [:robarnold]]

Comment on attachment 318175 [details] [diff] [review]
check policy patch v.1

Looks good to me

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #12)
> Try server builds - 
> https://build.mozilla.org/tryserver-builds/2008-04-28_09:[e-mail]-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).

Comment 15

[Jim Mathies [:jimm]]

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

[Alex Bustov]

Confirm - saving ok.

Comment 17

[Shawn Wilsher :sdwilsh]

Comment on attachment 318175 [details] [diff] [review]
check policy patch v.1

r=sdwilsh

Comment 18

[Damon Sicore (:damons)]

Can we do any testing here?  I know this is a blocker, but still.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 318175 [details] [diff] [review]
check policy patch v.1

a1.9=beltzner

Comment 20

[Shawn Wilsher :sdwilsh]

(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.

Comment 21

[Stephen Donner [:stephend] Not actively reading bugmail]

(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.)

Comment 22

[Jim Mathies [:jimm]]

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.

Comment 23

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/components/downloads/src/nsDownloadScanner.cpp 	1.19 

Comment 24

[Marcia Knous [:marcia]]

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.