Closed Bug 211348 Opened 23 years ago Closed 20 years ago

midas - crash refreshing page containing iframe containing editable document

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bc, Assigned: sicking)

References

Details

(5 keywords, Whiteboard: midas)

Attachments

(2 files)

If you host an iframe in a document and load a document into the iframe which has document.designMode = 'On', then load the page, edit the contents and refresh the document you will get a crash in Mozilla 1.4 win2k bug not Mozilla Trunk (1.5a) from 20030701. test case coming up
Attached file iframe contents —
Attached file crash test case —
load this, edit and reload to crash in 1.4
This test case does not crash when loaded from bugzilla but does crash when loaded off of a local web server. Talkback IDs coming up.
TB 21531707 nsQueryInterface::operator() [d:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 52] nsCOMPtr_base::assign_from_helper [d:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp, line 82] nsUndoCommand::IsCommandEnabled [d:/builds/seamonkey/mozilla/editor/libeditor/base/nsEditorCommands.cpp, line 76] nsControllerCommandTable::IsCommandEnabled [d:/builds/seamonkey/mozilla/embedding/components/commandhandler/src/nsControllerCommandTable.cpp, line 139] nsBaseCommandController::IsCommandEnabled [d:/builds/seamonkey/mozilla/embedding/components/commandhandler/src/nsBaseCommandController.cpp, line 118] XPTC_InvokeByIndex [d:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [d:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025] XPC_WN_CallMethod [d:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1285] js_Invoke [d:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845] js_Interpret [d:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2854] js_Invoke [d:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861] js_InternalInvoke [d:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936] JS_CallFunctionValue [d:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3529] nsJSContext::CallEventHandler [d:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1114] nsJSEventListener::HandleEvent [d:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp, line 183] nsEventListenerManager::HandleEventSubType [d:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line 1192] nsEventListenerManager::HandleEvent [d:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line 2193] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3302] nsXULCommandDispatcher::UpdateCommands [d:/builds/seamonkey/mozilla/content/xul/document/src/nsXULCommandDispatcher.cpp, line 390] GlobalWindowImpl::UpdateCommands [d:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 3460] nsFocusController::UpdateCommands [d:/builds/seamonkey/mozilla/dom/src/base/nsFocusController.cpp, line 168] nsFocusController::Focus [d:/builds/seamonkey/mozilla/dom/src/base/nsFocusController.cpp, line 325] nsEventListenerManager::HandleEvent [d:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line 1697] nsWindowRoot::HandleChromeEvent [d:/builds/seamonkey/mozilla/dom/src/base/nsWindowRoot.cpp, line 215] GlobalWindowImpl::HandleDOMEvent [d:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 816] nsXULDocument::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1278] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3289] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3282] nsXULElement::HandleChromeEvent [d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 4447] GlobalWindowImpl::HandleDOMEvent [d:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 816] nsDocument::HandleDOMEvent [d:/builds/seamonkey/mozilla/content/base/src/nsDocument.cpp, line 3616] nsEventStateManager::SendFocusBlur [d:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 4382] nsEventStateManager::SetContentState [d:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 4052] nsEventStateManager::PostHandleEvent [d:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 1922] PresShell::HandleEventInternal [d:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6433] PresShell::HandleEvent [d:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6317] nsViewManager::HandleEvent [d:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2314] nsView::HandleEvent [d:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 308] nsViewManager::DispatchEvent [d:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2050] HandleEvent [d:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 82] nsWindow::DispatchEvent [d:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1058] nsWindow::DispatchWindowEvent [d:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1075] nsWindow::DispatchMouseEvent [d:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5191] ChildWindow::DispatchMouseEvent [d:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5446] nsWindow::ProcessMessage [d:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4030] nsWindow::WindowProc [d:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1338] USER32.dll + 0x2ca8 (0x77e12ca8) USER32.dll + 0x2dc5 (0x77e12dc5) USER32.dll + 0x2f0f (0x77e12f0f) nsAppShellService::Run [d:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 479] main1 [d:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1284] main [d:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650] WinMain [d:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1672] WinMainCRTStartup() KERNEL32.DLL + 0x87f5 (0x7c4e87f5)
Also Incident ID 21531876 Stack Signature nsQueryInterface::operator() 763793c5 Incident ID 21531988 Stack Signature nsQueryInterface::operator() 763793c5
-->brade This sounds like a bug that was fixed; I'm surprised it wasn't fixed in 1.4 but maybe it didn't get approved or something. I'll investigate.
Assignee: mozeditor → brade
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: midas
*** Bug 211979 has been marked as a duplicate of this bug. ***
The bug is also in moz 1.5b (Gecko/20030810) If you reload the page then the following javascript: document.execCommand("bold", false, null); returns: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.execCommand]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://debug/webtracker-front2.0/rte/htmlEditor.html :: anonymous :: line 195" data: no] and the data of the body (document.body.innerHTML) isn't shown and document.body.innerHTML isn't changed if you change the body in the editor
I a crash in 1.5 when re-loading an iframe set to designMode when I have javascript that automatically writes to that iframe. The first time I load the HTML below (from local disk) the loading animation keeps on showing. If I hit stop, I can edit the text, but if I try re-loading, the animation will show for a while, and then the browser crashes. Incidentally, (I think) an extra blank line is added before "text" if I interchange the two javascript lines. <html><body> <table width="100%" height="100%"><tr><td bgcolor="#ffffff"> <iframe id="edit" width="100%" height="100%"></iframe> </td></tr></table> <script language="javascript"> <!-- document.getElementById('edit').contentWindow.document.designMode = "on"; document.getElementById('edit').contentWindow.document.writeln("text"); // --></script> </body></html>
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060328 SeaMonkey/1.5a no messages in JS console tested loading 'crash test case' Attachment id=126872 loading directly, and tested loading from local harddisk after saving a copy as 'Web Page, complete' Steps done: Load -> Edit -> Reload, Load -> Edit -> Shift-Reload, can this more than 2 years old bug now be closed, or a working testcase attached?
I'm seeing pretty much the same crash (a dangling mCommandContext pointer in nsBaseCommandController) when going back from a Midas-enabled document (maybe requires some editing) such as attachment 217099 [details]. Should this be a strong pointer, or should something be required to null it out? It doesn't look like either is happening.
I think Simon architected the command controllers for the editor. Hopefully he remembers why it isn't a strong pointer or what code is supposed to be cleaning it up.
mCommandContext should get nulled out when the thing that it points to goes away: http://lxr.mozilla.org/mozilla/search?string=SetCommandContext It's a weak ref to avoid ref cycles. Maybe it should be a real nsWeak ref.
Blocks: 331981
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.3?
Version: Other Branch → Trunk
A baked patch doesn't seem likely for 1.8.0.3, would be nice to get a fix in 1.8.0.4
Flags: blocking1.8.0.4?
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3-
The fix in bug 334515 fixes this one, readding blocking flags so it gets on the QA radar for verification of this variant.
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.4-
Flags: blocking1.8.0.4+
Flags: blocking1.8.0.3+
This has been fixed by the patch in bug 334515
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
reassign to sicking since he produced the patch
Assignee: brade → bugmail
Status: REOPENED → NEW
re-resolve as fixed
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Has the fix landed for 1.8.0.3 *and* 1.8.0.4? If so, we need to add fixed1.8.0.4.
Flags: blocking1.9a1?
Flags: blocking1.8.1?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: