shrirang khanzode Reporter
	Description • 24 years ago

filing as a seperate problem for mac only from bug 53347.


steps:

Go to this URL and type any thing you want. Press submit.
Observe that nothing happens 

Expected:
You will know everything is working if you see something like
this populate the large grey box on the left:

%FDF-1.2   1 0 obj <<  /FDF << /Fields [ << /V (You may type something in here 
if you wish)/T (Gibberish)>>  << /T (Submit)>> ]  /F 
(http://access.adobe.com/browser/pingform.pdf)/ID [ 
<160bbb62aaa6ebe41da6613b185c3724><843579f805b9c66041e13a566488878f> ] >>  >>  
endobj trailer << /Root 1 0 R   >> %%EOF 

(This is FDF -- a second file format associated with PDF and Acrobat forms.)

	Peter Lubczynski Assignee
	Comment 1 • 24 years ago

Mac only.

	av (gone)
	Comment 2 • 24 years ago

I must have done something not pure xp when doing files but cannot immediately 
see what. Peter, if you put a break point in 
nsPluginHostImpl::NewPluginURLStream on if(aPostData) you should be able to 
quickly figure it out.

	Peter Lubczynski Assignee
	Comment 3 • 24 years ago

We are passing "Mac HD/temp00000" as filename for NS_NewPostDataStream which is 
probably wrong. Mac paths are seperated by colons (::). I'll set a breakpoint 
where NS_NewPostDataStream is used elsewhere and cc:ing Pollmann.

	av (gone)
	Comment 4 • 24 years ago

Peter, as far as I understand this path we should pass to NS_NewPostDataStream 
is supposed to come from the plugin itself, so it is supposed to be just right 
on every platform. Could you somehow check what exactly we get from the plugin 
(I beleive the breakpoint should be set in _posturl (ns4xPlugin.cpp))

	Peter Lubczynski Assignee
	Comment 5 • 24 years ago

NS_NewPostDataStream fails if ":" aren't used as path seperators on the Mac. I'm 
creating a testing a patch now to replace "/" with ":"

	Eric Pollmann
	Comment 6 • 24 years ago

Is "/" a valid character in a filename on Mac?  If so, might replacing "/" with
":" be dangerous?

If you do make this change, please try to make it as specific to plugins and Mac
as possible - NS_NewPostDataStream is used by layout too, and we don't have
problems with Mac path delimiters there.

	Peter Lubczynski Assignee
	Comment 8 • 24 years ago

This patch is a Mac plugins only solution. I don't see another way to fix this 
without doing the replace. Comments?

	Peter Lubczynski Assignee
	Comment 9 • 24 years ago

Andrei,

In _posturl, buf (the filename) comes in as an url: file://Mac HD/filename

Before you call NS_NewPostDataStream, you strip off the file:// which makes it 
look like UNIX path. Guess this works in Windows, but Mac likes ':' folder 
seperators.

	av (gone)
	Comment 10 • 24 years ago

Oh, I see, it is not a file path but rather a url. (Man when you are on 
vacation you forget things so quickly.) Shouldn't we have some general way to 
convert file type urls into the native path? Does nsIFile provide something like 
this? I think that would be a right way to do this. Otherwise as Eric said we 
should be very careful. I wonder, why it works fine on Windows then?

What if to create a nsILocalFile object using this url and then just do GetPath 
off it (or what ever it has)? Maybe it will do the right thing for all 
platforms? You can steal the code from the place where I delete this file.

	Peter Lubczynski Assignee
	Comment 11 • 24 years ago

            nsCOMPtr<nsILocalFile> file;
            rv = NS_NewLocalFile(aPostData, PR_TRUE, 
getter_AddRefs(file));
            if (NS_FAILED(rv)) return rv;
            file->Normalize();  // doesn't help
            file->GetPath(&filename);

Unless I'm missing something, filename comes out the same way 
aPostData came in: file:///Mac HD/filename

I'll see how layout handles it.

	Eric Pollmann
	Comment 12 • 24 years ago

> I'll see how layout handles it.

Layout's input is a platform-native path, not a url, so it doesn't really have
to do any conversion - we take the value of the file input control (e.g.
Mac HD:filename), and  just directly use that.

Sorry, I don't know of anything generic that does this conversion, but there
might be something in the file: protocol handler in netwerk/protocol/file?

	Eric Pollmann
	Comment 13 • 24 years ago

Don't know if this is what you are looking for, but in nsFileChannel::Init() a
URL (mURI) looks to be converted into a localfile (localFile):

    // if we support the nsIURL interface then use it to get just
    // the file path with no other garbage!
    nsCOMPtr<nsIFileURL> fileURL = do_QueryInterface(mURI, &rv);
    if (NS_FAILED(rv)) {
        // this URL doesn't denote a file
        return NS_ERROR_MALFORMED_URI;
    }

    rv = fileURL->GetFile(getter_AddRefs(mFile));
    if (NS_FAILED(rv)) return rv;

    nsCOMPtr<nsILocalFile> localFile = do_QueryInterface(mFile);
    if (localFile)
        localFile->SetFollowLinks(PR_TRUE);

	Eric Pollmann
	Comment 15 • 24 years ago

The above patch worked okay on Windows with the test URL, does it also do the
trick on Mac?

	Peter Lubczynski Assignee
	Comment 16 • 24 years ago

I was just about to attach a patch similar to yours.

I tested yours on Mac, it's good, it works. I'll see if I can get reviews to get 
it in for mozilla 0.9.

	av (gone)
	Comment 17 • 24 years ago

Peter, do you think that now once we get this nsILocalFile object at the very 
beginning it would make sense to cache _it_ rather that the native path, so when 
the time to delete the file comes we don't need to convert the path into the 
nsILocalFile again. Unless this type of object is expensive in terms of 
footprint, I don't know.

	av (gone)
	Comment 18 • 24 years ago

It is good enough for me in its present form (and more likely to be accepted 
being smaller).

ra=av

	Marc Attinasi
	Comment 19 • 24 years ago

sr=attinasi

	Christopher Blizzard (:blizzard)
	Comment 20 • 24 years ago

a=blizzard for 0.9

	Peter Lubczynski Assignee
	Comment 21 • 24 years ago

Patch checked into the BRANCH:

/cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v  <--  
nsPluginHostImpl.cpp
new revision: 1.233.4.1; previous revision: 1.233

	Peter Lubczynski Assignee
	Comment 22 • 24 years ago

Patch checked into the TRUNK. Marking FIXED.

/cvsroot/mozilla/modules/plugin/nglsrc/nsPluginHostImpl.cpp,v  <--  
nsPluginHostImpl.cpp
new revision: 1.238; previous revision: 1.237

	shrirang khanzode Reporter
	Comment 23 • 24 years ago

verification blocked due to bug 78741

	shrirang khanzode Reporter
	Comment 24 • 24 years ago

crashing for me after I press the SUBMIT button on mac trunk 0516. Reopening...

	Peter Lubczynski Assignee
	Comment 25 • 24 years ago

Can you please attach a stack trace? Thanks!

	shrirang khanzode Reporter
	Comment 26 • 24 years ago

Looking at the trace, it seems like the same one as in 64645 that suresh posted.
Will recheck this today with Peter's fix for SetUpStreamListener

stack:

 Call Stack:    (Signature = free() 794e41bf) 
     
   free() 
                                                     [nsAllocatorManager.cp]
     
   PL_strfree() 
                                                     [strdup.c, line 44]
     
   nsPluginStreamListenerPeer::SetUpStreamListener() 
                                                     [nsPluginHostImpl.cpp, line 
1622]
     
   nsPluginStreamListenerPeer::OnStartRequest() 
                                                     [nsPluginHostImpl.cpp, line 
1413]
     
   nsStreamListenerTee::OnStartRequest() 
                                                     [nsStreamListenerTee.cpp, 
line 13]
     
   nsHttpChannel::ProcessNormal() 
                                                     [nsHttpChannel.cpp, line 
431]
     
   nsHttpChannel::ProcessResponse() 
                                                     [nsHttpChannel.cpp, line 
363]
     
   nsHttpChannel::OnStartRequest() 
                                                     [nsHttpChannel.cpp, line 
1974]
     
   nsOnStartRequestEvent::HandleEvent() 
                                                     
[nsRequestObserverProxy.cpp, line 108]
     
   nsARequestObserverEvent::HandlePLEvent() 
                                                     
[nsRequestObserverProxy.cpp, line 63]
     
   XPCOM_DLL + 0x6ecd8 (0x16ab38d8) 
                                                      
     
   XPCOM_DLL + 0x6eb54 (0x16ab3754) 
                                                      
     
   XPCOM_DLL + 0x1c0a0 (0x16a60ca0) 
                                                      
     
   WIDGET_DLL + 0x5a40 (0x16dd43e0) 
                                                      
     
   WIDGET_DLL + 0x5804 (0x16dd41a4) 
                                                      
     
   WIDGET_DLL + 0x2d9b0 (0x16dfc350) 
                                                      
     
   WIDGET_DLL + 0x19ce0 (0x16de8680) 
                                                      
     
   WIDGET_DLL + 0x195e0 (0x16de7f80) 
                                                      
     
   WIDGET_DLL + 0x18bf8 (0x16de7598) 
                                                      
     
   nsAppShellService::Run() 
                                                     [nsAppShellService.cpp, 
line 416]
     
   Netscape 6 + 0x469c (0x174bd1bc) 
                                                      

	Peter Lubczynski Assignee
	Comment 27 • 24 years ago

Marking FIXED (again). I'm pretty sure that my patch fixes the crash in that 
stack. Please re-open if not, but verify it's the same stack or a different one.

	shrirang khanzode Reporter
	Comment 28 • 24 years ago

yeah, I see the exact same results on mac as that on windows now. The submitted 
data result appears inside the textarea now. Verifed on mac 2001051704 build.