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



18 years ago
13 years ago


(Reporter: shrir, Assigned: akkzilla)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
seen on win 0503 trunk

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 :


Call Stack:    (Signature = nsWindowWatcher::GetExtantJSContext 297697d7) 
her.cpp, line 1829]
[d:\builds\seamonkey\mozilla\dom\src\base\nsWindowRoot.cpp, line 226]
[d:\builds\seamonkey\mozilla\dom\src\xul\nsJSXULDocument.cpp, line 488]
r.cpp, line 235]
, line 735]
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1152]
line 282]
[d:\builds\seamonkey\mozilla\xpcom\io\nsUnicharInputStream.cpp, line 261]
[d:\builds\seamonkey\mozilla\xpcom\ds\pldhash.c, line 454]
[d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp, line 739]

Comment 1

18 years ago
assigning to Simon, he worked with this area before.
Assignee: beppe → sfraser
Keywords: crash
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1

Comment 2

18 years ago
Can we get a better stack?

Comment 3

18 years ago
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_helper & {...}) line 553
* 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()

Comment 4

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

Comment 5

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

18 years ago
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?
Hardware: PC → All
Summary: crash after trying to open a doc file edited in wordpad in composer → Trying to open a doc file edited in wordpad in composer results in download dialog

Comment 7

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

Comment 8

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

18 years ago
PDT moving to 0.9.2 per triage session with beppe
Target Milestone: mozilla0.9.1 → mozilla0.9.2


18 years ago
Target Milestone: mozilla0.9.2 → mozilla1.0

Comment 10

18 years ago
-> editor owners
Assignee: sfraser → kin

Comment 11

17 years ago
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1


17 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 12

17 years ago
verified in trunk 20020819

Comment 13

17 years ago
Created attachment 98061 [details] [diff] [review]
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

17 years ago
--> Giving to composer folks.
Assignee: kin → syd
Component: Editor: Core → Editor: Composer
Target Milestone: Future → ---

Comment 15

17 years ago
cmanske and brade, could you comment on or review the proposed fix from

Comment 16

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

17 years ago
supplement to previous comments:

After trace into the original source code "baseWindow->Destroy();" in function:
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
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

17 years ago
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));

    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.
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?


17 years ago
Attachment #98061 - Attachment description: Modify incorrect usage of nsComPTR → patch v0.1

Comment 20

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

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

17 years ago
my build (from last Wednesday) doesn't crash when I try to open a pdf file
( on Mac OS9 (using Open
Location dialog).  However, I don't have this patch in my build.


16 years ago
Keywords: nsbeta1

Comment 23

16 years ago
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?
This bug is XP (or at least Windows/Linux/Solaris)
OS: Windows NT → All

Comment 25

16 years ago
--> akkana
Assignee: syd → akkana
Keywords: nsbeta1 → nsbeta1+

Comment 26

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

16 years ago
no crash in trunk 20021230

Comment 28

16 years ago
then, is it still a bug? if yes, what is the correct status when open files of
unkonwn type?
Keywords: crash

Comment 29

16 years ago
Composer triage team: this appears to be worksforme.
Keywords: nsbeta1+ → nsbeta1-
worksforme with windows Mozilla 2004020308
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.