Closed
Bug 5590
Opened 26 years ago
Closed 26 years ago
Bringing up InsertLink dialog without clicking in the edit window crashes appcore.
Categories
(Core :: DOM: Editor, defect, P1)
Tracking
()
VERIFIED
FIXED
M7
People
(Reporter: kinmoz, Assigned: cmanske)
Details
Just noticed this in the 04/27/99 Win32 build. I'm not sure if this is cross
platform or not.
To reproduce:
1. Run apprunner -editor
2. Without clicking in the content area, select Insert->Link from the menus.
You should now crash with the following stack trace:
nsCOMPtr_base::~nsCOMPtr_base() line 288 + 13 bytes
nsCOMPtr<nsIHTMLEditor>::~nsCOMPtr<nsIHTMLEditor>() + 15 bytes
nsEditorAppCore::GetSelectedElement(nsEditorAppCore * const 0x014fd140, const
nsString & {...}, nsIDOMElement * * 0x0012d468) line 1046 + 45 bytes
EditorAppCoreGetSelectedElement(JSContext * 0x015101e0, JSObject * 0x01d9fd80,
unsigned int 1, long * 0x01dbdf24, long * 0x0012d524) line 791 + 20 bytes
js_Invoke(JSContext * 0x015101e0, unsigned int 1, int 0) line 650 + 26 bytes
js_Interpret(JSContext * 0x015101e0, long * 0x0012dd28) line 2199 + 15 bytes
js_Invoke(JSContext * 0x015101e0, unsigned int 0, int 0) line 666 + 13 bytes
js_Interpret(JSContext * 0x015101e0, long * 0x0012e4cc) line 2199 + 15 bytes
js_Execute(JSContext * 0x015101e0, JSObject * 0x01da02f8, JSScript * 0x0157a340,
JSFunction * 0x00000000, JSStackFrame * 0x00000000, int 0, long * 0x0012e4cc)
line 815 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x015101e0, JSObject * 0x01da02f8,
JSPrincipals * 0x00000000, unsigned short * 0x0157a280, unsigned int 9, char *
0x0177a454, unsigned int 0, long * 0x0012e4cc) line 2390 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x015101a0, const nsString &
{...}, char * 0x0177a454, unsigned int 0, nsString & {...}, int * 0x0012e508)
line 124 + 64 bytes
nsWebShellWindow::ExecuteJavaScriptString(nsString & {...}) line 1466 + 41 bytes
nsWebShellWindow::ExecuteStartupCode() line 1496
nsWebShellWindow::OnEndDocumentLoad(nsWebShellWindow * const 0x014ffa3c, nsIURL
* 0x01501610, int 0) line 1135
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x01504ae0, nsIURL *
0x01501610, int 0) line 2371
nsDocLoaderImpl::FireOnEndDocumentLoad(int 0) line 1459
nsDocLoaderImpl::LoadURLComplete(nsIURL * 0x01563400, nsISupports * 0x01563680,
int 0) line 1722
nsDocumentBindInfo::OnStopBinding(nsDocumentBindInfo * const 0x01563680, nsIURL
* 0x01563400, unsigned int 0, unsigned short * 0x01564520) line 2289
OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x015644d0)
line 591 + 45 bytes
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x015644d4) line 471 + 12
bytes
PL_HandleEvent(PLEvent * 0x015644d4) line 476 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x012d1c40) line 437 + 9 bytes
_md_EventReceiverProc(void * 0x084c04b4, unsigned int 49445, unsigned int 0,
long 19733568) line 799 + 9 bytes
USER32! 77e71250()
Assignee | ||
Comment 1•26 years ago
|
||
This problem exists because we do not set focus on initial page loading.
Is this still blocked by the lack of focus management?
If yes, this should be fixed by making focus work correctly.
There are probably other operations that would cause a crash because of the
lack of initial focus.
Updated•26 years ago
|
Target Milestone: M6
Comment 2•26 years ago
|
||
Changed to milestone M6
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
Assignee | ||
Comment 3•26 years ago
|
||
Fix depends on general focus problem fixing. Not sure when that will be done,
so setting this to M7
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 4•26 years ago
|
||
Caret is now being set during editor startup, so no more crash.
You need to log in
before you can comment on or make changes to this bug.
Description
•