Closed
Bug 78841
Opened 23 years ago
Closed 21 years ago
Trying to open a doc file edited in wordpad in composer results in download dialog
Categories
(SeaMonkey :: Composer, defect, P1)
SeaMonkey
Composer
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: shrir, Assigned: akkzilla)
Details
Attachments
(1 file)
796 bytes,
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
assigning to Simon, he worked with this area before.
Reporter | ||
Comment 3•23 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<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•23 years ago
|
||
Hrmm, we're trying to show the unknown content-type download dialog, which law just changed. Cc some folks.
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•23 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•23 years ago
|
||
I tried to cancel the nsIRequest, but that did not help. Anyone?
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•23 years ago
|
||
PDT moving to 0.9.2 per triage session with beppe
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla1.0
Comment 11•23 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
Comment 12•22 years ago
|
||
verified in trunk 20020819
Comment 13•22 years ago
|
||
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•22 years ago
|
||
--> Giving to composer folks.
Assignee: kin → syd
Component: Editor: Core → Editor: Composer
Target Milestone: Future → ---
Comment 15•22 years ago
|
||
cmanske and brade, could you comment on or review the proposed fix from leon.zhang@sun.com?
Comment 16•22 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•22 years ago
|
||
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•22 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)); 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•22 years ago
|
||
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?
Updated•22 years ago
|
Attachment #98061 -
Attachment description: Modify incorrect usage of nsComPTR → patch v0.1
Comment 20•22 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•22 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•22 years ago
|
||
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.
Assignee | ||
Comment 23•22 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?
Assignee | ||
Comment 26•22 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•22 years ago
|
||
no crash in trunk 20021230
Comment 28•22 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•22 years ago
|
||
Composer triage team: this appears to be worksforme.
Comment 30•21 years ago
|
||
worksforme with windows Mozilla 2004020308
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•