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.
wouldn't firefox have a similar issue? is there a way to solve it for both?
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
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.
Yeah, it prevents you from saving into the directory in Firefox 1.5 RC1 (just got a chance to update here).
It sounds like FF is doing what we should be doing; disabling the save button for folders that are protected...
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
Assignee: mikepinkerton → nick.kreeger
Not an enhancement, at any rate.
Severity: enhancement → normal
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.
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?
Target Milestone: --- → Camino1.0
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.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
Status: NEW → ASSIGNED
Flags: camino1.0? → camino1.0+
Fixed. BTW, I never saw a hang. If anyone still does, please sample and reopen.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
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...
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
(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.
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?
(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.
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.
So the "hang" only happens if you save as "HTML Complete". Investigating.
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.
Really fixed now. Note that you'll see a generic "downloading failed" error until bug 315305 lands.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.