seen on mac OSX commercial build 2003-04-21-03-trunk -Browse a page -Select File | Save Page As in the save as dialog make sure Format Web Page Complete is selected -click save the web page an associated files are not saved as expected.
This probably isn't relevant, but I just tried this on WinXP with Mozilla build 2003041804, and it worked fine.
argh! Why is email@example.com still the owner of anything? he doesn't work on mozilla anymore! reassigning to SOMEONE to get attention here..
Assignee: law → asa
Adding smfr to cc list, as he checked in mac specific drag and drop related code.
It might be me. Looking...
datapoint: WFM 2003042008 win2k trunk.
WFM, MacOSX, an optimized build, updated to the tip
WFM with 2003042103, downgrading severity to critical.
Severity: blocker → critical
Tracy, what's the URL of the page that failed for you?
Please try this test with a new profile. It fails when using a profile created with this build. It doesn't fail using an existing profile. I used www.mozilla.org as the web page to save.
back to Blocker status as this occurs in a new profile. Conrad, are you able to duplicate this issue? thx!
Severity: critical → blocker
Profile stuff ==> to ccarlen
Assignee: asa → ccarlen
I'm able to with today's nightly. I'm not able to with my debug build which was pulled friday afternoon.
Status: NEW → ASSIGNED
If downloads.rdf is not in the profile - and it's not in new profiles as it gets made whenever the first download happens - the download will fail. If a download is done using an older build and downloads.rdf is created it will work with today's build.
WFM MachO build 2003042108
Summary: Save Page As fails to save webpage → Save Page As fails to save webpage from new profile
Found the problem: It's caused by this WARNING: Cannot tell if file:///Users/conrad/Library/Mozilla/Profiles/fresh/te7oh278.slt/downloads.rdf is a directory or file, file /Users/conrad/Development/TRUNK/MachObj/mozilla/netwerk/base/src/nsURLHelperUnix.cpp, line 75 The new impl of IsDirectory in nsLocalFileOSX fails if the file does not exist and so it can't be determined whether it's a file or a directory. This seems reasonable. Obviously, the easy fix is to have IsDirectory happily return NS_OK no matter what. Or, change the caller to tolerate failure?
Created attachment 121206 [details] [diff] [review] patch This patch makes it so that errors are not returned from IsDirectory or IsFile. That is what the unix impl does. An error from IsDirectory() causes complete failure of nsDownloadManager::Init which, BTW, causes the app to crash on quitting. The error handling in this code needs looking at, but this at least allows it to work.
I'd prefer that we fix callers to deal with errors from IsDirectory and IsFile, since it makes more sense for them to return errors when the file/dir doesn't exist yet. I think the Unix impl is broken in that regard.
This question is going to sound really dumb, but I'm going to ask it anyway. Why is Mac build using nsURLHelperUnix.cpp when there exists a file called nsURLHelperMac.cpp?
Created attachment 121212 [details] [diff] [review] better patch The problem is that here: http://lxr.mozilla.org/seamonkey/source/rdf/base/src/nsRDFXMLDataSource.cpp#555, it depends not just on whether an error is returned, but *what* error. See the comment in the patch.
Attachment #121206 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Thanks Conrad!! Respins underway now.
verified with respin 2003-04-21-14-trunk and the crash on quit is gone too. :-)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.