314803 - Downloading doesn't check permissions first

Status: RESOLVED FIXED

(Camino Graveyard :: Downloading, defect)

Description

[shawn]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051101 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051101 Camino/1.0+

When downloading to a folder where you don't have permission on the filesystem to make changes (or even access it) the download just keeps on spinning at 0.0 bytes per second.

Reproducible: Always

Steps to Reproduce:
1. In Terminal: mkdir temp;chmod 700 temp;sudo chown (someone else) temp
2. Open the browser to http://www.caminobrowser.com/
3. Attempt to save the page into the temp directory created in step 1

Actual Results:  
Perpetual download accomplishing nothing

Expected Results:  
Dialog letting the user know not to shoot themselves in the foot

Discovered alongside a permissions issue in Mac OS X where afp://something on one machine doesn't transfer permissions correctly to the local machine given certain things that don't matter a whole lot to Camino.

Basically if I attempt to download somewhere I can't, the browser should realize this and let me know.

Replicated on two different 10.4 machines with that build and a few builds prior.

Comment 1

[Mike Pinkerton (not reading bugmail)]

wouldn't firefox have a similar issue? is there a way to solve it for both?

Comment 2

[Nick Kreeger]

Reporter:

Could you please conduct this test on the latest firefox (1.5 rc1?)
Then please report your results so we can determine if we need to file this as a core bug

Comment 3

[Nick Kreeger]

Pretty Please!

Comment 4

[shawn]

Heh, just got the comments now. :-)

I'll try testing with 1.5RC1 in the morning, but the save button gets disabled in Firefox' 1.5 branch nightly from the 25th in 10.3 so you can't save into the directory.

Like I said, I'll check in the morning when I get back to my RC1 but it looks like the behavior doesn't span browsers.

Comment 5

[shawn]

Yeah, it prevents you from saving into the directory in Firefox 1.5 RC1 (just got a chance to update here).

Comment 6

[Samuel Sidler (old account; do not CC)]

It sounds like FF is doing what we should be doing; disabling the save button for folders that are protected...

Comment 7

[Nick Kreeger]

If this is causing a crash, and it is something on our side, I would nominate this to be a 1.0 blocker.

I'm taking, I'll take a good look tommorow

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not an enhancement, at any rate.

Comment 9

[shawn]

Not a crash that I've noticed. It just doesn't ever start downloading (because it can't) but it doesn't ever seem to realize it. The user can stop the download or use the browser normally while it runs in its little hamster wheel. It just doesn't prevent the user from getting into that state, even though it lets the user get out of it.

Which seems odd to me - I thought that using an OS component like the save dialog would handle that automatically. I haven't looked at the source, though. So I really have nothing more than an educated guess to go on with that.

Comment 10

[Samuel Sidler (old account; do not CC)]

For all intents and purposes, this sounds like a hang. Adding that keyword. Also, targeting for 1.0 and requesting blocking.

Jasper, I believe you reproduced this? If so, can you confirm it?

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It doesn't stick around hanging long enough for me to get a sample, but I've got a happy crash log coming right up.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Crash log

Comment 13

[Simon Fraser [no longer active]]

I think it's probably hard to find out if you can really write to a directory without actually doing so. For example, it's possible to save over an existing file in a read-only directory, if you're saving with the same name.

So I'm fixing this by
1. fixing the crash
2. showing errors for common download problems (currently no write permissions,
and disk full).

Comment 14

[Simon Fraser [no longer active]]

Fixed.

BTW, I never saw a hang. If anyone still does, please sample and reopen.

Comment 15

[shawn]

Attachment: Resulting trace from Sampler

Haven't used Sampler before, so hoping this covers something that helps...

In this order, I:
1. Started recording
2. Attempted to save into a directory I had no access to
3. Let it spin for about five or ten seconds
4. Stopped the download
5. Stopped recording

Like I said, I haven't used Sampler before, so apologies if this just takes up space. But hopefully it will shed at least a little light on what I've run into...

Comment 16

[shawn]

Reopened.

As in my summary, it doesn't freeze the browser or crash. It just doesn't prevent the user from downloading into a directory they don't have access to (check against FF1.5RC1). It also doesn't realize that it hasn't made (and can't make) any progress in downloading the file.

Comment 17

[Simon Fraser [no longer active]]

This isn't a hang, whatever it may look like. Camino is not sucking CPU, and you can interact with other windows. It's just not progressing on downloading the file.

Maybe this is a branch thing; I was testing with trunk.

Comment 18

[shawn]

(In reply to comment #17)
> This isn't a hang, whatever it may look like. Camino is not sucking CPU, and
> you can interact with other windows. It's just not progressing on downloading
> the file.

Exactly! I didn't file it as a crash because of those very reasons.

> Maybe this is a branch thing; I was testing with trunk.

Glad to hear it has disappeared in the trunk. I'll keep an eye out to see if it stops showing up for me as well.

Comment 19

[Simon Fraser [no longer active]]

Can you please test with today's branch nightly and tell me what you see please. What at the permissions on the destination folder, and what download are you using?

Comment 20

[shawn]

(In reply to comment #19)
> Can you please test with today's branch nightly and tell me what you see
> please. What at the permissions on the destination folder, and what download
> are you using?
> 

I got the same thing, using the setup described in the bug summary (directory owned by root set to 700).

For this, I've tested just downloading the default "Welcome to Camino"-type page you get on launch. I discovered it trying to save a tarball onto a network drive where I expected to have write permission but didn't.

Comment 21

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

WFM 2005110604 (v1.0a1+).  I get the error sheet in the download manager about not having permissions when attempting to save into /System or a root-owned 700 temp on my Desktop.

Comment 22

[Simon Fraser [no longer active]]

So the "hang" only happens if you save as "HTML Complete". Investigating.

Comment 23

[Simon Fraser [no longer active]]

Attachment: Patch

This patch fixes the bug by notifying the download when creating the "foo Files" folder fails. Note that we need the patch in bug 315305 to get the correct error message back in some cases.

Comment 24

[Simon Fraser [no longer active]]

Really fixed now. Note that you'll see a generic "downloading failed" error until bug 315305 lands.