78841 - Trying to open a doc file edited in wordpad in composer results in download dialog

Status: RESOLVED WORKSFORME

(SeaMonkey :: Composer, defect, P1)

Description

[shrirang khanzode]

seen on win 0503 trunk

steps:
1 open wordpad on windows and type something (anything is enough to crash ;)
2 save the file as "word for windows 6.0" 
3 Launch 6.x composer and open this file
4 An alert saying "this type of file cannot be edited..blah..blah "

Click ok and the browser crashes :

stack:

Call Stack:    (Signature = nsWindowWatcher::GetExtantJSContext 297697d7) 
     
   nsWindowWatcher::GetExtantJSContext 
                                            
[d:\builds\seamonkey\mozilla\embedding\components\windowwatcher\src\nsWindowWatc
her.cpp, line 1829]
     
   NS_NewWindowRoot 
                                            
[d:\builds\seamonkey\mozilla\dom\src\base\nsWindowRoot.cpp, line 226]
     
   NS_NewScriptXULDocument 
                                            
[d:\builds\seamonkey\mozilla\dom\src\xul\nsJSXULDocument.cpp, line 488]
     
   nsUnknownContentTypeHandler::Show 
                                            
[d:\builds\seamonkey\mozilla\xpfe\components\ucth\src\nsUnknownContentTypeHandle
r.cpp, line 235]
     
   nsExternalAppHandler::SetUpTempFile 
                                            
[d:\builds\seamonkey\mozilla\uriloader\exthandler\nsExternalHelperAppService.cpp
, line 735]
     
   nsDocLoaderImpl::OnProgress 
                                            
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1152]
     
   nsResProtocolHandler::AppendSubstitution 
                                            
[d:\builds\seamonkey\mozilla\netwerk\protocol\res\src\nsResProtocolHandler.cpp, 
line 282]
     
   nsProxyObjectCallInfo::operator= 
                                             
     
   ConverterInputStream::Read 
                                            
[d:\builds\seamonkey\mozilla\xpcom\io\nsUnicharInputStream.cpp, line 261]
     
   PL_DHashTableEnumerate 
                                            
[d:\builds\seamonkey\mozilla\xpcom\ds\pldhash.c, line 454]
     
   nsLocalFile::Append 
                                            
[d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp, line 739]

Comment 1

[rubydoo123]

assigning to Simon, he worked with this area before.

Comment 2

[Simon Fraser [no longer active]]

Can we get a better stack?

Comment 3

[shrirang khanzode]

here is a better one:

ns_if_addref(nsIChromeEventHandler * 0x04ab8554) line 1129 + 15 bytes
nsDocShell::GetChromeEventHandler(nsDocShell * const 0x04e204a0, 
nsIChromeEventHandler * * 0x05c08894) line 718 + 19 bytes
GlobalWindowImpl::SetDocShell(GlobalWindowImpl * const 0x05c087b0, 
nsIDocShell * 0x04e204a0) line 449 + 54 bytes
nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x04e204a0) line 4858
nsWebShell::GetInterface(nsWebShell * const 0x04e204c4, const nsID & 
{...}, void * * 0x0012fa30) line 329 + 19 bytes
nsGetInterface::operator()(const nsID & {...}, void * * 0x0012fa30) line 
37 + 31 bytes
nsCOMPtr<nsIDOMWindowInternal>::assign_from_helper(const nsCOMPtr_helper 
& {...}, const nsID & {...}) line 971 + 18 bytes
nsCOMPtr<nsIDOMWindowInternal>::nsCOMPtr<nsIDOMWindowInternal>(const 
nsCOMPtr_helper & {...}) line 553
nsUnknownContentTypeHandler::ShowProgressDialog(nsUnknownContentTypeHandler 
* const 0x05c0b564, nsIHelperAppLauncher * 0x0510f134, nsISupports * 
0x04e204a0) line 173 + 27 bytes
nsExternalAppHandler::ShowProgressDialog() line 990 + 69 bytes
nsExternalAppHandler::LaunchWithApplication(nsExternalAppHandler * const 
0x0510f134, nsIFile * 0x00000000, int 0) line 1133
nsExternalAppHandler::OnStartRequest(nsExternalAppHandler * const 
0x0510f130, nsIRequest * 0x050c8560, nsISupports * 0x00000000) line 876 
+ 20 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 
0x050cfcd0, nsIRequest * 0x050c8560, nsISupports * 0x00000000) line 242 
+ 34 bytes
nsFileChannel::OnStartRequest(nsFileChannel * const 0x050c8568, 
nsIRequest * 0x050cc724, nsISupports * 0x00000000) line 453 + 37 bytes
nsOnStartRequestEvent::HandleEvent() line 108 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x050dab44) line 64
PL_HandleEvent(PLEvent * 0x050dab44) line 588 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e6d030) line 518 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00010260, unsigned int 49412, unsigned 
int 0, long 15126576) line 1069 + 9 bytes
USER32! 77e71820()
00e6d030()

Comment 4

[Simon Fraser [no longer active]]

Hrmm, we're trying to show the unknown content-type download dialog, which law 
just changed. Cc some folks.

Comment 5

[Bill Law]

I'll look at this some more when I get chance.  But there's a perhaps related
bug 78943.  Part of that bug (not explained well there; a more thorough
explanation is in bug 52454) was an abnormal uriloader situation arising in that
context.  Something similar may be going on here.

Comment 6

[Simon Fraser [no longer active]]

I can't repro now, but what does happen is the Downloading dialog shows up after 
OKing the "Can't edit documents of this type" dialog.

Law: what can we do to just abort the download, and prevent this dialog from 
being shown?

Comment 7

[Simon Fraser [no longer active]]

I tried to cancel the nsIRequest, but that did not help. Anyone?

Comment 8

[Bill Law]

That comes from the guts of the uriloader.  I think it fires off some sort of
CanhandleContent to the "original" window but that's probably something generic
(no different between browser and composer).  I don't really know how this
works, mscott would know.  Scott?

Comment 9

[Phil Peterson]

PDT moving to 0.9.2 per triage session with beppe

Comment 10

[Simon Fraser [no longer active]]

-> editor owners

Comment 11

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 12

[leon.zhang]

verified in trunk 20020819

Comment 13

[leon.zhang]

Attachment: patch v0.1

The second part of the patch modify  the incorrect usage of nsComPTR.

The first part is the result of searching the same error in editor module.

mozila no crash when applied this patch.

Comment 14

[kinmoz]

--> Giving to composer folks.

Comment 15

[kinmoz]

cmanske and brade, could you comment on or review the proposed fix from
[e-mail]?

Comment 16

[Charles Manske]

The fix looks simple enough to me! 
If returning NS_ERROR_ABORT prevents code from continuing and trying to 
download (and then crashing!) then it seems like a good fix.
Note that editorShell is going away, so we need to remember this when we 
move this code into nsIEditingSession.

Comment 17

[leon.zhang]

supplement to previous comments:

After trace into the original source code "baseWindow->Destroy();" in function:
nsEditorShell::EndPageLoad,
I found that the following callling relationship is:
  baseWindow->Destroy() --> nsChromeTreeOwner::Destroy()
                               -->  mXULWindow->Destroy() 
                                         --> nsWebShellWindow::Destroy()

  In nsWebShellWindow::Destroy,code below was executed: 
    1) webProgress->RemoveProgressListener(this); 
          remove a element of mListenerInfoList.
    2) nsXULWindow::Destroy()  --> shellAsWin->Destroy();
          empty the  mListenerInfoList,and count of elemets is zero.
  
When return from "nsEditorShell::EndPageLoad" to
"nsDocLoaderImpl::FireOnStateChange",
Although elements count of mListenerInfoList is 0, still meet code below:
    info = NS_STATIC_CAST(nsListenerInfo*,mListenerInfoList.ElementAt(count));
    (note: value of count is 1)
    
SO crash happen.

Comment 18

[leon.zhang]

Current patch works, becuase never call "baseWindow->Destroy()" any more.

After analyze further more, I think the codes below:
  if (mCloseWindowWhenLoaded)
  {
    //TODO: Would it be possible to simply change channel URL to "about:blank"
    //      so we leave window up with empty page instead of closing it?
    nsCOMPtr<nsIBaseWindow> baseWindow;
    GetTreeOwner(mDocShell, getter_AddRefs(baseWindow));
    NS_ENSURE_TRUE(baseWindow, NS_ERROR_ABORT);
    baseWindow->Destroy();

    return NS_ERROR_ABORT;
  }

should be:

  if (mCloseWindowWhenLoaded)
  {
    //TODO: Would it be possible to simply change channel URL to "about:blank"
    //      so we leave window up with empty page instead of closing it?

    return NS_ERROR_ABORT;
  }

The main reason is :
  we will not need the variable: baseWindow.

If possible, I will give a new patch according to this thought.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Um... so if we never call Destroy() how do we:

1)  Close the editor window
2)  Clean up the objects (if (1) works fine).

It seems the real problem here is pointed out in comment 17 -- why is "count"
equal to 1?

Comment 20

[leon.zhang]

after discuss with bz, current status is:
1) the first dialog is necessary, give warning info to users.
2) the second download dialog should not be actived.

so current questions is how to destroy the second dialog correctly.

Comment 21

[Simon Fraser [no longer active]]

The trunk crashes in different ways if I try to open a PDF file on Mac, from 
composer. That crash (composer commands stuff) is masking this bug.

Comment 22

[Kathleen :Brade]

my build (from last Wednesday) doesn't crash when I try to open a pdf file
(http://www.adobe.com/products/golive/pdfs/overview.pdf) on Mac OS9 (using Open
Location dialog).  However, I don't have this patch in my build.

Comment 23

[Akkana Peck]

What's the current status of this?  And Simon mentions mac, but the OS here is
Windows only -- should this bug's OS be changed to ALL?

Comment 24

[Boris Zbarsky [:bzbarsky]]

This bug is XP (or at least Windows/Linux/Solaris)

Comment 25

[Syd Logan]

--> akkana

Comment 26

[Akkana Peck]

My build doesn't crash either, when I run mozilla -edit file.pdf and click OK to
open in xpdf.  Is anyone still seeing this?  Is a patch still needed?

Comment 27

[leon.zhang]

no crash in trunk 20021230

Comment 28

[leon.zhang]

then, is it still a bug? if yes, what is the correct status when open files of
unkonwn type?

Comment 29

[Samir Gehani]

Composer triage team: this appears to be worksforme.

Comment 30

[Asa Dotzler [:asa]]

worksforme with windows Mozilla 2004020308