2nd editor win on docShell crashes embedding app (suggestion to prevent creating 2nd editor)

RESOLVED INCOMPLETE

Status

()

--
critical
RESOLVED INCOMPLETE
16 years ago
9 years ago

People

(Reporter: depman1, Unassigned)

Tracking

({crash})

Trunk
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs code-level retesting], URL)

(Reporter)

Description

16 years ago
Mozilla 1.1b Gecko/20020815. TestEmbed (/mozilla/embedding/qa/testembed)
1. In the embedding app, get nsIEditingSession and domWindow objects.
2. Call nsIEditingSession->MakeWindowEditable(nsIDOMWindow). Internally calls
SetEditor
3. Call nsIEditingSession->SetupEditorOnWindow((nsIDOMWindow). Also calls
SetEditor internally.
4.
(Reporter)

Comment 1

16 years ago
oops, need to add what happens.
Result is that a 2nd editor is called on the DocShell but init method not
called. Timers are set off. embedding app crashes with unhandled exception:

nsQueryInterface::operator()(const nsID & {...}, void * * 0x0012ed34) line 47 +
23 bytes
nsCOMPtr<nsIEditor>::assign_from_helper(const nsCOMPtr_helper & {...}, const
nsID & {...}) line 922 + 18 bytes
nsCOMPtr<nsIEditor>::nsCOMPtr<nsIEditor>(const nsQueryInterface & {...}) line 566
nsComposerCommandsUpdater::SelectionIsCollapsed() line 287
nsComposerCommandsUpdater::TimerCallback() line 222 + 8 bytes
nsComposerCommandsUpdater::Notify(nsComposerCommandsUpdater * const 0x031ec2ec,
nsITimer * 0x031ecde0) line 311
nsTimerImpl::Fire() line 341
handleTimerEvent(TimerEventType * 0x031edc00) line 399
PL_HandleEvent(PLEvent * 0x031edc00) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00dbada0) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x003902dc, unsigned int 49467, unsigned int 0,
long 14396832) line 1077 + 9 bytes
USER32! 77e71820()
00db

Suggestion to prevent the 2nd editor from being created. Could be useful in
general browser or composer context as well as embedding.
(Reporter)

Updated

16 years ago
Keywords: crash

Comment 2

16 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
(Reporter)

Comment 3

14 years ago
this bug needs to be reassigned
(Reporter)

Updated

14 years ago
Assignee: mjudge → mozeditor
QA Contact: sujay → editor
Assignee: mozeditor → nobody
Whiteboard: [needs code-level retesting]

Comment 4

9 years ago
Resolving as INCOMPLETE because of lack of enough information to evaluate this bug.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.