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)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

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()
Priority: P3 → P1
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.
Target Milestone: M6
Changed to milestone M6
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
Fix depends on general focus problem fixing. Not sure when that will be done, so setting this to M7
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Caret is now being set during editor startup, so no more crash.
Status: RESOLVED → VERIFIED
verified fix in 5/6 build.
You need to log in before you can comment on or make changes to this bug.