The default bug view has changed. See this FAQ.

midas - crash refreshing page containing iframe containing editable document

RESOLVED FIXED

Status

()

Core
Editor
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: bc, Assigned: sicking)

Tracking

(5 keywords)

Trunk
crash, fixed1.8.0.3, fixed1.8.0.4, fixed1.8.1, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.0.3 +
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: midas)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
Created attachment 126871 [details]
iframe contents
(Reporter)

Comment 2

14 years ago
Created attachment 126872 [details]
crash test case

load this, edit and reload to crash in 1.4
(Reporter)

Comment 3

14 years ago
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.
(Reporter)

Comment 4

14 years ago
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) 
(Reporter)

Comment 5

14 years ago
Also Incident ID 21531876
Stack Signature 	nsQueryInterface::operator() 763793c5

Incident ID 21531988
Stack Signature 	nsQueryInterface::operator() 763793c5

Comment 6

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

Comment 7

14 years ago
*** Bug 211979 has been marked as a duplicate of this bug. ***

Comment 8

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

Comment 9

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

Comment 10

11 years ago
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.

Comment 12

11 years ago
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.

Comment 13

11 years ago
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-
Depends on: 334515
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
Last Resolved: 11 years ago
Keywords: fixed1.8.0.3, fixed1.8.1, testcase
Resolution: --- → FIXED

Updated

11 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 17

11 years ago
reassign to sicking since he produced the patch
Assignee: brade → bugmail
Status: REOPENED → NEW

Comment 18

11 years ago
re-resolve as fixed
Status: NEW → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED

Comment 19

11 years ago
Has the fix landed for 1.8.0.3 *and* 1.8.0.4?  If so, we need to add fixed1.8.0.4.  
Keywords: fixed1.8.0.4

Updated

11 years ago
Flags: blocking1.9a1?
Flags: blocking1.8.1?
You need to log in before you can comment on or make changes to this bug.