153609 - [Website Testing] download of sound clips fails to save (save link as)

Status: RESOLVED WORKSFORME

(Camino Graveyard :: General, defect)

Description

[Albert Kammerer]

I am using Mac OS X (10.1.5) and Navigator 0.3.0 (22 June). Go to CDNow and select any music CD you would like that offers sound clips of the songs (I tried this with both RealMedia and Windows Media clips). Select one of the clips and then "Save link as..." from the contextual menu. Even before the save as dialog appears, Navigator crashes on my system. I am attaching my crash log.

Comment 1

[Albert Kammerer]

Attachment: Crashlog for CDNow.com

Comment 2

[saari (gone)]

Eeep, that's a new stack to me. Do you see this with any other downloads?

 #0   0x0001164c in PerformSave__15nsHeaderSniffer
 #1   0x00010cd0 in
OnStateChange__15nsHeaderSnifferP14nsIWebProgressP10nsIRequestUiUi
 #2   0x00121338 in OnStartRequest__19nsWebBrowserPersistP10nsIRequestP11nsISupports
 #3   0x004a62e8 in ProcessNormal__13nsHttpChannel
 #4   0x004a5e3c in ProcessResponse__13nsHttpChannel
 #5   0x004ad4f0 in OnStartRequest__13nsHttpChannelP10nsIRequestP11nsISupports
 #6   0x00181b90 in HandleEvent__21nsOnStartRequestEvent
 #7   0x001813b0 in HandlePLEvent__23nsARequestObserverEventP7PLEvent
 #8   0x0505642c in PL_HandleEvent

Comment 3

[Albert Kammerer]

This is nothing I have ever seen before...

Comment 4

[Mike Pinkerton (not reading bugmail)]

brade? is this different from the one you fixed a day or two ago?

Comment 5

[Dave Barrowman]

I can reproduce this crash using a build from 6/25.

Go to 
http://cdnow.com/cgi-bin/mserver/SID=1394745392/pagename=/RP/CDN/FIND/album.html/artistid=CINERAMA/itemid=1355772
and use the context menu "Save As..." on one of the sound file links.  Crash
occurs immediately.

Comment 6

[Kathleen :Brade]

The possible fix for this crash was checked in 6/25 around lunch time.  Can
someone checker newer bits?  I don't see the crash when I go to the site and
then choose Save Link As from context menu (but it doesn't save either).

I am going to resolve this bug as fixed (for the crasher).  Bug 152044 is for
the saving not happening.

Comment 7

[Kathleen :Brade]

change of plans... reopening this bug to cover the save issue

I think this save scenario is more common that "save as" in the view source window.

Comment 8

[Steve Dagley]

Looks to be a related to Necko, the version(s) of nsLocalFile used in Chimera
and the need to get the Mac version of uriloader into Chimera.  Adding more
folks to the cc: list since darin is on vacation.

Since debugging any part of the code outside the Chimera front end itself seems
to be a Zen exercise some observations before I call it a night:

Doing a Save Link As... on one of the music links results in the following
errors to the console:

WARNING: Cannot tell if file:///private/tmp/-sav3tmp is a directory or file,
file nsIOServiceUnix.cpp, line 71
spec=/source=wmf
WARNING: malformed url: no scheme, file nsStandardURL.cpp, line 726
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsExternalHelperAppService.cpp, line 209

This raises some questions:

1) Chimera Necko is still using nsIOServiceUnix which seems bad, needs to be
switched over to nsIOServiceMac

2) Is the WARNING from nsIOServiceUnix because we're now passing in a
nsLocalFileOSX which is expected to be a nsLocalFileUnix? 

3) Is the warning from nsStandardURL benign?  The URL it's complaining about
looks something like this:

<http://cdnow.com/cgi-bin/mserver/SID=1427955170/pagename=/RP/SHARE/soundclip.html/UPC=6700424022/disc=01/track=06/source=wmf>

Comment 9

[Bradley Baetz (:bbaetz)]

nsIOService::GetURLSpecFromFile is, for the unix case, geting the native path,
escaping it, and then checking if its a directory, adding a / if it is.

The call to nsLocalFileOSX::IsDirectory is obviously failing, and this is
probably cause by the filename (which a url is then created from, giving you
that warning) being odd.

This is because the escaping will replace : with /, which is almost certainly
wrong for the mac

nsLocalFileMac.cpp has:

    // colons [originally slashes, before SwapSlashColon() usage above]
    // need encoding; use %2F which is a forward slash
    escPath.ReplaceSubstring(":", "%2F");

You probably  need the same for osx.

Comment 10

[Conrad Carlen (not reading bugmail)]

> 1) Chimera Necko is still using nsIOServiceUnix which seems bad, needs to be
switched over to nsIOServiceMac

No, because nsIOServiceMac assumes the the directory separator is ':' and has to
do the swap slash/colon business. The paths from the nsLocalFile impl in
nsLocalFileOSX.cpp return Unix-style POSIX paths with '/' as the separator.

Something else must be wrong.

Comment 11

[Bradley Baetz (:bbaetz)]

> The paths from the nsLocalFile impl in
> nsLocalFileOSX.cpp return Unix-style POSIX paths with '/' as the separator.

If yuo add a printf after teh call to GetNativePath in
nsIOService::GetURLSpecFromFile (in nsIOServiceUnix.cpp), what does it print out?

Comment 12

[Conrad Carlen (not reading bugmail)]

Good idea. Build in progress now. I'll do that when it finishes...

Comment 13

[Gagan]

dougt can possibly comment on the nsIOService/nsLocalFile issues. Andreas can
answer the warning (which I think is benign too) cc'ing them

Comment 14

[Andreas Otte]

The warning in nsStandardURL happens when ParseURL is fed with something that
really does not look like an url. I don't think it is the given url, that looks
clean, instead ParseURL gets "/source=wmf" as absolute url and complains about
it rightfully. So I think nsStandardUrl is just the victim ... not the cause.

Comment 15

[saari (gone)]

this appears to be fixed now, marking worksforme