Save Page As fails to save webpage from new profile

VERIFIED FIXED

Status

Core Graveyard
File Handling
--
blocker
VERIFIED FIXED
15 years ago
2 years ago

People

(Reporter: tracy, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({smoketest})

Trunk
PowerPC
Mac OS X
smoketest

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

15 years ago
This probably isn't relevant, but I just tried this on WinXP with Mozilla build
2003041804, and it worked fine.

Comment 2

15 years ago
argh! Why is law@netscape.com still the owner of anything? he doesn't work on
mozilla anymore!
reassigning to SOMEONE to get attention here..
Assignee: law → asa

Comment 3

15 years ago
Adding smfr to cc list, as he checked in mac specific drag and drop related code.
(Assignee)

Comment 4

15 years ago
It might be me. Looking...

Comment 5

15 years ago
datapoint: WFM 2003042008 win2k trunk.

Comment 6

15 years ago
WFM, MacOSX, an optimized build, updated to the tip

Comment 7

15 years ago
WFM with 2003042103, downgrading severity to critical. 
Severity: blocker → critical
(Assignee)

Comment 8

15 years ago
Tracy, what's the URL of the page that failed for you?
(Reporter)

Comment 9

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

Comment 10

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

Comment 12

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

Comment 13

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

Comment 14

15 years ago
WFM MachO build 2003042108

Updated

15 years ago
Summary: Save Page As fails to save webpage → Save Page As fails to save webpage from new profile
(Assignee)

Comment 15

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

Comment 16

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

Comment 17

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

Comment 18

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

Comment 19

15 years ago
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

Updated

15 years ago
Attachment #121212 - Flags: superreview+
(Assignee)

Comment 20

15 years ago
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 21

15 years ago
Thanks Conrad!!

Respins underway now.
(Reporter)

Comment 22

15 years ago
verified with respin 2003-04-21-14-trunk

and the crash on quit is gone too. :-)
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.