77256 - MFCembed crashes accessing ftp protocol

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P1)

Description

[Michael Dunn]

Tested with 4-23-01 build

Comment 1

[Adam Lock]

Chak

Comment 2

[Chak Nanga]

It's crashing when trying to look up a NULL key. Here's the stack trace:

_hashValue(const void * 0x00000000) line 137 + 3 bytes
PL_HashTableLookup(PLHashTable * 0x0012f89c, const void * 0x00000000) line 371 + 
10 bytes
nsHashtable::Get(nsHashKey * 0x00000000) line 306 + 49 bytes
nsStreamConverterService::FindConverter(const char * 0x026871f0, nsCStringArray 
* * 0x0012fa50) line 393 + 22 bytes
nsStreamConverterService::AsyncConvertData(nsStreamConverterService * const 
0x0261cc10, const unsigned short * 0x0012fb7c, const unsigned short * 
0x0012fae0, nsIStreamListener * 0x026867a0, nsISupports * 0x02659e60, 
nsIStreamListener * * 0x0265f8e0) line 555 + 16 bytes
nsDocumentOpenInfo::RetargetOutput(nsIRequest * 0x02659e60, const char * 
0x026850a0, const char * 0x014b17d4, nsIStreamListener * 0x00000000) line 443 + 
102 bytes
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x02659e60, nsISupports * 
0x00000000) line 328 + 32 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0265f8d0, 
nsIRequest * 0x02659e60, nsISupports * 0x00000000) line 241 + 16 bytes
nsFTPChannel::OnStartRequest(nsFTPChannel * const 0x02659e70, nsIRequest * 
0x02658610, nsISupports * 0x00000000) line 513 + 51 bytes
nsFTPDirListingConv::OnStartRequest(nsFTPDirListingConv * const 0x02657e10, 
nsIRequest * 0x026aeb60, nsISupports * 0x00000000) line 363
DataRequestForwarder::DelayedOnStartRequest(nsIRequest * 0x026ae730, nsISupports 
* 0x00000000) line 183
DataRequestForwarder::OnDataAvailable(DataRequestForwarder * const 0x026aeb64, 
nsIRequest * 0x026ae730, nsISupports * 0x00000000, nsIInputStream * 0x026ae940, 
unsigned int 0, unsigned int 554) line 231 + 19 bytes
nsOnDataAvailableEvent::HandleEvent() line 173 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0261ce34) line 64
PL_HandleEvent(PLEvent * 0x0261ce34) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00979a00) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x055b03cc, unsigned int 49360, unsigned int 0, 
long 9935360) line 1069 + 9 bytes
USER32! 77e71820()
00979a00()

Comment 3

[Chak Nanga]

The crash as indicated above happens when run from the Embed dir

However, running mfcembed and going to an ftp URL from the dist/win32_d.obj/bin 
causes the following assertion:

NS_IMETHODIMP nsScrollPortView::SetScrolledView(nsIView *aScrolledView)
{
.....
  NS_ASSERTION(count <= 1,"Error scroll port has too many children");
.....
}

Ignoring the assertion just leaves a blank area in mfcembed - but we do not 
crash.

Comment 4

[Doug Turner (:dougt)]

the content viewer is going to try to load XUL (directory.xul).  Do you support 
this?  If not, you might want to set the preference "network.dir.generate_html" 
which will produce html/text instead.

Comment 5

[Chak Nanga]

As i mentioned above i get an assertion saying that "Error scroll port has too 
many children". I choose "ignore" and the all i see is a blank screen.

However, if i choose to go to the ftp URL (after the steps above) i see the FTP 
listing just fine in mfcemed.

What's the cause/meaning of the above assert and what needs to be done to fix 
it?

Comment 6

[Chak Nanga]

*** Bug 78238 has been marked as a duplicate of this bug. ***

Comment 7

[Chak Nanga]

Latest status:

Seems to be working fine with the latest build of mfcembed. I can go to 
ftp.netscape.com and can navigate the dirs OK.
However, i get an assert (in the code shown below) if i do the following:

1. Go to ftp://ftp.netscape.com
2. Click on "bin"
3. Click on "ls"

Now you should see the assert in the debug build at the following code:

NS_IMETHODIMP
nsFTPChannel::SetNotificationCallbacks(nsIInterfaceRequestor* 
aNotificationCallbacks)
{
    mCallbacks = aNotificationCallbacks;

    // FIX these should be proxies!
    if (mCallbacks) {
        (void)mCallbacks->GetInterface(NS_GET_IID(nsIProgressEventSink), 
                                       getter_AddRefs(mEventSink));

        (void)mCallbacks->GetInterface(NS_GET_IID(nsIPrompt),
                                       getter_AddRefs(mPrompter));
        NS_ASSERTION ( mPrompter, "Channel doesn't have a prompt!!!" );
        (void)mCallbacks->GetInterface(NS_GET_IID(nsIFTPEventSink),
                                       getter_AddRefs(mFTPEventSink));
        
        (void)mCallbacks->GetInterface(NS_GET_IID(nsIAuthPrompt),
                                       getter_AddRefs(mAuthPrompter));
        NS_ASSERTION ( mAuthPrompter, "Channel doesn't have an auth prompt!!!" 
);
    }
    return NS_OK;
}

Cc:ing Conrad and danm

Comment 8

[Conrad Carlen (not reading bugmail)]

I'd have to see where that particular channel is made and why it doesn't have a
prompt. Doug - Since this happens when displaying a sub-directory and not on the
initial load, is there something different about the way in which those
different channels are made?

Comment 9

[Judson Valeski]

chak, we recently flipped the switch from xul directory listings to html. are
"thinks ok" using html? if so, the summary of this bug should be changed to
reflect that xul listings are still broken. dougt knows what pref to switch to
toggle back and forth.

Comment 10

[Chak Nanga]

Even in the HTML dir listing mode i'm unable to download any files (for ex, the 
.exe files in the /pub subdirs)

I keep hitting the Prompter Assert as mentioned above.

As far as XUL listings are concerned what exactly needs to be done wrt the Embed 
packaging standpoint

Comment 11

[Judson Valeski]

I'm actually not sure, I was hoping you could tell us :-). I suspect that we
need to distribute the dir listing xul though.

Comment 12

[Chak Nanga]

Jud : I'll talk to dougt regarding the xul dir listing issue.

I just tried the ftp URL in mozilla and am seeing the same assertions as from 
mfcembed. However, i get the save as dialog for the exe's etc. in mozilla (which 
i do not get in mfcembed) 

Comment 13

[Doug Turner (:dougt)]

I can browse FTP sites fine with MFCEmbed using HTML content.  

The assertions that you are seeing are caused by the 
nsExternalAppHandler::RetargetLoadNotifications setting a nsIInterfaceRequestor 
on the FTP channel without it supporting nsIPrompt or nsIAuthPrompt.  I filed a 
bug against [e-mail] regarding this.  Once I pass these two assertions, 
the download happens successfully.

As far as the XUL tree widget (which can be enabled by setting 
the pref network.dir.generate_html to false) not displaying correctly in 
mfcembed, I haven't got a clue.  well, I got a clue, but I am not sure if it 
will help:  I am guessing that the MFC embedding application does not have a XUL 
chrome and that the directory viewer xul needs something like that.  Try 
changing the content type of the docshell tree to xul...

Comment 14

[Chak Nanga]

Targetting to 0.9.1

Comment 15

[Chak Nanga]

MfcEmbed does not crash anymore but i still cannot download, say an exe, since 
the unknown content handler does not display.
(Please note that i can do this from the dist/win32_d.obj/bin dir but not from 
the Embed package)

So i modified the embed packager to include the appropriate files needed for the 
helperapp dialog (the xul file, the .js file which impls the component etc - 
i'll submit this patch).

Despite this i still get an assert since the do_createInstance() as shown 
below fails and the dialog does not get displayed:

NS_IMETHODIMP nsExternalAppHandler::OnStartRequest(nsIRequest *request, 
nsISupports * aCtxt)
{
  NS_ENSURE_ARG(request);

  <snip>

  if (alwaysAsk)
  {
    // do this first! make sure we don't try to take an action until the user 
tells us what they want to do
    // with it...
    mReceivedDispostionInfo = PR_FALSE; 

    // invoke the dialog!!!!! use mWindowContext as the window context parameter 
for the dialog request
    mDialog = do_CreateInstance( NS_IHELPERAPPLAUNCHERDLG_CONTRACTID, &rv );
    NS_ENSURE_SUCCESS(rv, rv);

<snip>
}

The only thing is that the helper appdlg component is implemented in JS and is 
present in the components dir.

Comment 16

[Chak Nanga]

Attachment: Patch to copy the reqd. helperappdlg files to the Embed package

Comment 17

[Conrad Carlen (not reading bugmail)]

As of last night this used to work in PPEmbed. As of this morning it does not.
The ucth dialog comes up but, probably due to the following error, none of its
items respond.

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Can not get JavaScript object for DOM object arg 5
[nsIWindowWatcher.openWindow]"  nsresult: "0x8057002a
(NS_ERROR_XPC_CANT_GET_JSOBJECT_OF_DOM_OBJECT)"  location: "JS frame ::
Conrad:Seamonkey:moz:mozilla:dist:viewer_debug:Components:nsHelperAppDlg.js ::
anonymous :: line 84"  data: no]
************************************************************

Clicking on any item in the dialog produces this:

JavaScript error: 
 line 0: dialog is not defined

Comment 18

[Chak Nanga]

Conrad : Do you run PPEmbed from the Embed dir or from the bin dir?

Comment 19

[Conrad Carlen (not reading bugmail)]

I'm running it from the bin dir. It's not a problem of missing chrome, but of
some difference between the embedded and seamonkey context. Probably another
issue altogether but worth looking at while you're here.

Comment 20

[Bill Law]

nsHelperAppDlg.js :: line 84 is a call to nsIWindoWatcher::OpenWindow, whose 5th
arg is the argument(s) to be passed via the window.arguments[] array.  There are
none in this case, which should be OK, I think.  nsWindowWatcher::OpenWindow
calls nsWindowWatcher::ConvertSupportsTojsvals, which simply returns NS_OK if
this argument is null.

It seems that maybe the error is happening in xpconnect going from the .js into
nsIWindowWatcher::OpenWindow.  I'm not sure why that would be failing in this
case, but not others.

Any ideas on that?

Comment 21

[Chak Nanga]

This issue seems to be taking different paths depending on the day you try to 
debug it. Here's todays flavour:

1. Go to ftp://ftp.netscape.com
2. Click on pub
3. Choose the .gz file in the dir listing. The ucth handler dialog shows up. In 
that dialog choose the option to save file to disk and save the file.
4. The file will be saved just fine to the disk (Not with the same filename you 
gave it, but, that's a different issue)
5. You'll crash

Looks like we're crashing when we get a msg. to close the ucth dialog.

Here's the stack trace:

nsDebug::Assertion(const char * 0x017d6910 
??_C@_0DJ@KMGL@You?5can?8t?5dereference?5a?5NULL?5nsC@, const char * 0x017d6954 
??_C@_0N@NHHF@mRawPtr?5?$CB?$DN?50?$AA@, const char * 0x017df0e8 
??_C@_0CB@MCGB@?4?4?2?4?4?2?4?4?2dist?2include?2nsCOMPtr?4h@, int 649) line 290 
+ 13 bytes
nsDebug::PreCondition(const char * 0x017d6910 
??_C@_0DJ@KMGL@You?5can?8t?5dereference?5a?5NULL?5nsC@, const char * 0x017d6954 
??_C@_0N@NHHF@mRawPtr?5?$CB?$DN?50?$AA@, const char * 0x017df0e8 
??_C@_0CB@MCGB@?4?4?2?4?4?2?4?4?2dist?2include?2nsCOMPtr?4h@, int 649) line 434 
+ 21 bytes
nsCOMPtr<nsIScriptContext>::operator->() line 649 + 34 bytes
nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x02fe66e0, 
nsIDOMEventReceiver * 0x028f74c8, nsIDOMEvent * 0x03580944) line 392 + 11 bytes
nsXBLPrototypeHandler::BindingDetached(nsXBLPrototypeHandler * const 0x02fe66e0, 
nsIDOMEventReceiver * 0x028f74c8) line 518
nsXBLPrototypeBinding::BindingDetached(nsXBLPrototypeBinding * const 0x02fe6860, 
nsIDOMEventReceiver * 0x028f74c8) line 565 + 30 bytes
nsXBLBinding::ExecuteDetachedHandler(nsXBLBinding * const 0x02fe60c0) line 1368
ExecuteDetachedHandler(nsHashKey * 0x02fe6080, void * 0x02fe60c0, void * 
0x00000000) line 971
_hashEnumerate(PLHashEntry * 0x02fe6040, int 7, void * 0x0012f7c4) line 193 + 26 
bytes
PL_HashTableEnumerateEntries(PLHashTable * 0x02f52fc8, int (PLHashEntry *, int, 
void *)* 0x10026e90 _hashEnumerate(PLHashEntry *, int, void *), void * 
0x0012f7c4) line 413 + 15 bytes
nsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x01686820 
ExecuteDetachedHandler(nsHashKey *, void *, void *), void * 0x00000000) line 359 
+ 21 bytes
nsSupportsHashtable::Enumerate(int (nsHashKey *, void *, void *)* 0x01686820 
ExecuteDetachedHandler(nsHashKey *, void *, void *), void * 0x00000000) line 159
nsBindingManager::ExecuteDetachedHandlers(nsBindingManager * const 0x028ecb30) 
line 981
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x028dd260, 
nsIPresContext * 0x028de270, nsEvent * 0x0012f890, nsIDOMEvent * * 0x0012f85c, 
unsigned int 1, nsEventStatus * 0x0012f8d8) line 563
nsWebShell::FireUnloadEvent(nsWebShell * const 0x028dd89c) line 262 + 45 bytes
nsWebShell::Destroy(nsWebShell * const 0x028dd784) line 1391 + 21 bytes
nsWebBrowser::SetDocShell(nsWebBrowser * const 0x028dde80, nsIDocShell * 
0x00000000) line 1265
nsWebBrowser::InternalDestroy(nsWebBrowser * const 0x028dde80) line 99
nsWebBrowser::Destroy(nsWebBrowser * const 0x028dde90) line 848
CBrowserView::DestroyBrowser() line 249
CBrowserView::OnDestroy() line 151
CWnd::OnWndMsg(unsigned int 2, unsigned int 0, long 0, long * 0x0012fb0c) line 
1825
CWnd::WindowProc(unsigned int 2, unsigned int 0, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x01e9e34c {CBrowserView hWnd=0x035204e8}, HWND__ * 
0x035204e8, unsigned int 2, unsigned int 0, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x035204e8, unsigned int 2, unsigned int 0, long 0) line 368
AfxWndProcBase(HWND__ * 0x035204e8, unsigned int 2, unsigned int 0, long 0) line 
220 + 21 bytes
USER32! 77e719d0()
USER32! 77e71982()
NTDLL! 77f763a3()
CBrowserFrame::OnClose() line 113
CWnd::OnWndMsg(unsigned int 16, unsigned int 0, long 0, long * 0x0012fd98) line 
1825
CWnd::WindowProc(unsigned int 16, unsigned int 0, long 0) line 1585 + 30 bytes
AfxCallWndProc(CWnd * 0x01e9e028 {CBrowserFrame hWnd=0x0049053e}, HWND__ * 
0x0049053e, unsigned int 16, unsigned int 0, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x0049053e, unsigned int 16, unsigned int 0, long 0) line 
368
AfxWndProcBase(HWND__ * 0x0049053e, unsigned int 16, unsigned int 0, long 0) 
line 220 + 21 bytes
U

Comment 22

[Chak Nanga]

Attachment: Patch to fix the crash

Comment 23

[Chak Nanga]

The above patch definitely fixes the crash, but, i'm not really sure why the 
"boundContext" is coming up NULL.
We were crashing because we were accessing "boundContext" eventhough it was 
NULL without checking for its validity.

I need someone to r= this.

Also, we still need to work on the packaging of the new helperappdialog stuff 
for embedding.

Comment 24

[Bill Law]

I'll review it, you can't go wrong with a null-pointer check: r=law.

I'm also curious as to how this situation arises.  I've got at least one other
similar bug, I think.

What's the issue with the packaging?

Comment 25

[Chak Nanga]

Hi Bill : 

The packaging issue is to include the helperappdlg component and the other 
required files(.xul,.dtd etc) into the Embed package. 

Basically we need to add all the required files to 
embedding/config/basebrowser-unix/win as shown in 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=33173

I'm still having a problem even with those changes to the packaging - the 
do_CreateInstance(NS_IHELPERAPPLAUNCHERDLG_CONTRACTID) call fails.
(please see my comments dated 001-05-04 06:55 in this bug)

Since the helperapp dialog component is implemented as a .js file someone 
mentioned that we may need some other additional file(s) to handle .js 
components. Any ideas?

Comment 26

[Chak Nanga]

Addition to my prev post...

The embed package will essentially be a jar file named "embed.jar" which 
contains all the xul files etc. which are needed in an embedding env.

Comment 27

[Chak Nanga]

I'm still having trouble with the packaging. I can have the helperapp xul 
dialogs show up OK when run from the dist/win32_d.obj/bin dir but not from the 
Embed dir.

In addition to the changes in 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=33173 i'm also copying 
the jsloader.dll and xp3250.dll which are needed for js component loading since 
the helperapp dlg is implemented as a js component.

I'm not sure, whether we need more files for supporting xul content or if i 
still need some more files for handling js components (in addition to the two 
dlls mentioned above)

Cc:ing blizzard

Comment 28

[Chak Nanga]

->0.9.3

Comment 29

[Chak Nanga]

->0.9.4

Comment 30

[Chak Nanga]

This one's fixed as we're overriding the helper app dialog in MfcEmbed now
[See http://bugzilla.mozilla.org/show_bug.cgi?id=90538 for more info]

Comment 31

[David Epstein]

verified.