Closed Bug 5691 Opened 26 years ago Closed 25 years ago

tabing into a hidden field causes app error

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: charles.tuffli, Assigned: hyatt)

Details

i verified this on windows 95, nt4.s3, and windows 2000 (beta 3) with the 1999-04-28-09/mozilla-win32 build to reproduce 0) apprunner.exe -mail 1) click on the "new msg" button 2) when the window comes up, close the "Cc:" field 3) click in the "To:" field 4) press the tab key and the application stops an error dialog comes up saying "The instruction at 0x00f76567 referenced memory at 0x0000000c. The memory could not be read" with softice (debugger) the call stack looks like ... raptorwidget!.text+a8b5 ... raptorwidget!.text+ ... raptorwidget!.text+ ... raptorwidget!.text+ ... raptorwidget!.text+ ... raptorwidget!.text+ ... raptorview!.text+1390 ... raptorview! ... raptorview! ... raptorview! ... raptorhtml!. ... raptorhtml!. ... raptorhtml!. ... raptorhtml!. ... raptorhtml!. ... raptorwidget!.text+5567 at 015f:01096567 (ss:ebp 0167:0077f8fc) the output from apprunner was M:\mozilla\package\bin>M:\mozilla\package\bin\apprunner.exe -mail nsComponentManager: Using components dir: M:\mozilla\package\bin\components width was not set height was not set defaultReading file... Reading file...Done The Messenger component is available. Initializing... Messenger has been bootstrapped! The Composer component is available. Initializing... Composer has been bootstrapped! Reading file... Reading file...Done Reading file... Reading file...Done Reading file... Reading file...Done Loading preferences for account: account1 nsGetMailboxRoot(pcocd2.intel.com) = c:\Program Files\Netscape\Users\test\Mail folder = Path of mailbox://pcocd2.intel.com/ is c:\Program Files\Netscape\Users\test\Mail (succeeded) nsGetMailboxRoot(Inbox) = folder = Inbox Path of mailbox://Inbox is (null) (failed) nsGetMailboxRoot(Inbox) = (null) folder = Inbox Path of mailbox://Inbox is (null) (failed) MsgNewMessage from XUL newMsg from XUL ComposeMessage from XUL We succesfully obtained a nsIMsgSend interface.... We succesfully obtained a nsIMsgPost interface.... We succesfully obtained a nsIMsgCompFields interface.... Created a compose appcore from Messenger, name=ComposeAppCore:925401710290Compos e: StartUp Compose: argument: name=ComposeAppCore:925401710290 Looking up EditorAppCore... Creating EditorAppCore... Created nsEditorAppCore editor app core (925401711602) correctly added to app cores manager initalizing the editor app core Attaching to WebShellWindow[] Compose: get composeAppCore=ComposeAppCore:925401710290 initalizing the compose app core
I'm wondering if this bug could be caused by the same thing as http://bugzilla.mozilla.org/show_bug.cgi?id=5533 ?
no, this is not related to 5533. 5533 is fixed, and this problem still exists. I don't think this is editor-related at all, since you aren't even interacting with the editor widget. The To field is a text widget, and text widgets won't be implemented using ender code until M7.
Assignee: ducarroz → trudelle
Component: Composition → XP Toolkit/Widgets
Product: MailNews → Browser
still crashing with today's build. reassign bug to xptoolkit team
Assignee: trudelle → karnaze
That's a lot of 'Raptor's on the stack, and Karnaze owns the native text widgets, reassigning.
Assignee: karnaze → hyatt
Severity: major → critical
David, can you take a look at this. When I launch apprunner from the debugger with -mail as an argument, apprunner is toast. And Peter refers to a stack but it isn't included in this report.
Status: NEW → ASSIGNED
Target Milestone: M7
i tried this out on the 1999060308 win32 build and the app error is gone. i still don't think that the resulting behavior is correct because it takes two tabs to get from the "To:" field to the "Bcc:" field if the "Cc:" field is closed.
Target Milestone: M7 → M10
Target Milestone: M10 → M14
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Apparently, nobody has seen the original problem in months. resolving as worksforme. please file any other problems in separate bug reports.
Status: RESOLVED → VERIFIED
Linux Redhat 6.0 (1999-11-02-12 M11) Win_nt 4.0 (1999-11-02-09 M11) Mac (1999-11-02-08 M11) Using the scenario from the original report, I do not see the problem.
You need to log in before you can comment on or make changes to this bug.