Closed Bug 126277 Opened 23 years ago Closed 22 years ago

Crash when scroll the charset in Preferences

Categories

(SeaMonkey :: Themes, defect)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: amyy, Assigned: bryner)

References

Details

(5 keywords, Whiteboard: [adt2 RTM])

Attachments

(1 file)

Build: 02-18 trunk build on Mac10.1.2

Steps:
1. Launch browser, and go to Preferences.
2. Go to Languages category, in default charset area, move up or down key to
select the charset ( can not use up/down arrow due another bug).

Actual result:
The menu item of category will be highlighted and moved up/down then CRASH.

Expected result:
The menu item of default charset will be highlighted and moved up/down without
crash.

Please change the component if not an i18n problem, thanks!
Crash data in .log file:

Date/Time:  2002-02-18 13:49:03 -0800
OS Version: 10.1.2 (Build 5P48)

Command:    Netscape 6
PID:        319

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0:
 #0   0x03330664 in ActivateMenu__11nsMenuFrameFi
 #1   0x03330654 in ActivateMenu__11nsMenuFrameFi
 #2   0x0332c524 in HideChain__16nsMenuPopupFrameFv
 #3   0x0334ccdc in Rollup__23nsMenuDismissalListenerFv
 #4   0x02d6d858 in Destroy__8nsWindowFv
 #5   0x03493de0 in _dt__6nsViewFv
 #6   0x03494214 in Destroy__6nsViewFv
 #7   0x03209ffc in Destroy__7nsFrameFP14nsIPresContext
 #8   0x032073d8 in Destroy__16nsContainerFrameFP14nsIPresContext
 #9   0x03314ac8 in Destroy__10nsBoxFrameFP14nsIPresContext
 #10  0x0332d100 in Destroy__16nsMenuPopupFrameFP14nsIPresContext
 #11  0x0330eca4 in DestroyFrames__11nsFrameListFP14nsIPresContext
 #12  0x0332f1c4 in DestroyPopupFrames__11nsMenuFrameFP14nsIPresContext
 #13  0x0332f24c in Destroy__11nsMenuFrameFP14nsIPresContext
 #14  0x0330eca4 in DestroyFrames__11nsFrameListFP14nsIPresContext
 #15  0x032073c8 in Destroy__16nsContainerFrameFP14nsIPresContext
 #16  0x03314ac8 in Destroy__10nsBoxFrameFP14nsIPresContext
 #17  0x0330eca4 in DestroyFrames__11nsFrameListFP14nsIPresContext
 #18  0x032073c8 in Destroy__16nsContainerFrameFP14nsIPresContext
 #19  0x03314ac8 in Destroy__10nsBoxFrameFP14nsIPresContext
 #20  0x0330eca4 in DestroyFrames__11nsFrameListFP14nsIPresContext
 #21  0x032073c8 in Destroy__16nsContainerFrameFP14nsIPresContext
 #22  0x03314ac8 in Destroy__10nsBoxFrameFP14nsIPresContext
 #23  0x0330eca4 in DestroyFrames__11nsFrameListFP14nsIPresContext
 #24  0x032073c8 in Destroy__16nsContainerFrameFP14nsIPresContext
 #25  0x03314ac8 in Destroy__10nsBoxFrameFP14nsIPresContext
 #26  0x0330eca4 in DestroyFrames__11nsFrameListFP14nsIPresContext
 #27  0x032073c8 in Destroy__16nsContainerFrameFP14nsIPresContext
 #28  0x032e39e0 in Destroy__13ViewportFrameFP14nsIPresContext
 #29  0x0333cae4 in Destroy__12FrameManagerFv
 #30  0x0321e034 in Destroy__9PresShellFv
 #31  0x02a8ef54 in Destroy__18DocumentViewerImplFv
 #32  0x02a8fca8 in Show__18DocumentViewerImplFv
 #33  0x032294d0 in UnsuppressAndInvalidate__9PresShellFv
 #34  0x0322daf8 in ProcessReflowCommands__9PresShellFi
 #35  0x0322d318 in HandlePLEvent__FP11ReflowEvent
 #36  0x005f5e20 in PL_HandleEvent
 #37  0x005f5c8c in PL_ProcessPendingEvents
 #38  0x0059af6c in ProcessPendingEvents__16nsEventQueueImplFv
 #39  0x02d72abc in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv
 #40  0x02d72880 in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord
 #41  0x0221eb14 in DoRepeaters__8RepeaterFRC11EventRecord
 #42  0x02d86938 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord
 #43  0x02d86510 in DoMessagePump__16nsMacMessagePumpFv
 #44  0x02d85e8c in Run__10nsAppShellFv
 #45  0x02398d4c in Run__17nsAppShellServiceFv
 #46  0x004c8ba4 in main1__FiPPcP11nsISupports
 #47  0x004c967c in main

Thread 1:
 #0   0x7000497c in syscall
 #1   0x70557600 in BSD_waitevent
 #2   0x70554b80 in CarbonSelectThreadFunc
 #3   0x7002054c in _pthread_body

Thread 2:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x705593ec in CarbonOperationThreadFunc
 #3   0x7002054c in _pthread_body

Thread 3:
 #0   0x70044cf8 in semaphore_timedwait_signal_trap
 #1   0x70044cd8 in semaphore_timedwait_signal
 #2   0x7003f2b8 in _pthread_cond_wait
 #3   0x70283ea4 in TSWaitOnConditionTimedRelative
 #4   0x7027d748 in TSWaitOnSemaphoreCommon
 #5   0x702c2078 in TimerThread
 #6   0x7002054c in _pthread_body

Thread 4:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x70250ab0 in TSWaitOnCondition
 #3   0x7027d730 in TSWaitOnSemaphoreCommon
 #4   0x70243d14 in AsyncFileThread
 #5   0x7002054c in _pthread_body

Thread 5:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x7055b884 in CarbonInetOperThreadFunc
 #3   0x7002054c in _pthread_body

Thread 6:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x70026a2c in _pthread_become_available
 #3   0x70026724 in pthread_exit
 #4   0x70020550 in _pthread_body


PPC Thread State:
  srr0: 0x03330664 srr1: 0x0200f030                vrsave: 0x00000000
   xer: 0x0000000e   lr: 0x03330654  ctr: 0x03494260   mq: 0x00000000
    r0: 0x03330654   r1: 0xbfffe740   r2: 0x0344a000   r3: 0x00000000
    r4: 0x05c09c70   r5: 0x00000000   r6: 0x00000000   r7: 0xbfffe718
    r8: 0x033f4b60   r9: 0x0346b580  r10: 0x6a4cde51  r11: 0x047c44b2
   r12: 0x034a666c  r13: 0x00000000  r14: 0x00000036  r15: 0x00681ea0
   r16: 0x00681ea0  r17: 0xbfffee90  r18: 0x0005a278  r19: 0x00002407
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004234  r23: 0x700042c8
   r24: 0x00000004  r25: 0x000006eb  r26: 0x8081ab5c  r27: 0x0005acd0
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x00000000  r31: 0x00000001

**********

Keywords: crash, intl
QA Contact: ruixu → ylong
I saw this crash on 02-04 too, but not on 01-24 trunk build.

-> nebeta1
Severity: normal → major
Keywords: nsbeta1, regression
I think this is a generic menu scrolling problem, reassign to hyatt, cc to pinkerton
Assignee: yokoyama → hyatt
Component: Internationalization → XP Toolkit/Widgets: Menus
Yes, I saw crash when scroll the serch engine names too.
Component: XP Toolkit/Widgets: Menus → Internationalization
Component: Internationalization → XP Toolkit/Widgets: Menus
Nav triage team needs info: can anyone else reproduce this in current builds?
Whiteboard: [need info]
Yuying, does this still crash?
Keywords: qawanted
Yes, still crash on 03-11 trunk build.
yuying, is this crash limited to Mac OS X? also, have you tried with both the
modern and class themes? just curious.

fwiw, i cannot get this to crash on win2k or linux...and strangely, haven't
managed to crash on Mac OS 10.1.3 with either modern or classic theme...
03-11 trunk build, the crash on both Mac OS 10.1.3 and Mac9.1-JA with classic
theme but no crash on medern theme.
Talk back ID: 3914739
*** Bug 130562 has been marked as a duplicate of this bug. ***
->themes
Assignee: hyatt → hewitt
Component: XP Toolkit/Widgets: Menus → Themes
QA Contact: ylong → pmac
Nav triage team: nsbeta1+
Keywords: nsbeta1nsbeta1+
Whiteboard: [need info] → [need info] [nav2]
This looks like the return of bug 64022 and bug 63452.  Seems the theme rewrite
set -moz-user-focus:ignore on the menulists.
converting nav2->adt2, ->1.0
Whiteboard: [need info] [nav2] → [adt2]
Target Milestone: --- → mozilla1.0
ylong- still crash these day?

are we sure you will always get "view"? do you need to check view is null or not
before use it ?

663   if (aActivateFlag) {
...
666       nsIView* view = nsnull;
667       menuPopup->GetView(mPresContext, &view);
668       nsCOMPtr<nsIViewManager> viewManager;
669       view->GetViewManager(*getter_AddRefs(viewManager));
...
671       viewManager->ResizeView(view, rect);
...
684       viewManager->UpdateView(view, rect, NS_VMREFRESH_IMMEDIATE);
685       viewManager->SetViewVisibility(view, nsViewVisibility_kShow);
686 
687   } else {
688     nsIView* view = nsnull;
689     menuPopup->GetView(mPresContext, &view);
690     NS_ASSERTION(view, "View is gone, looks like someone forgot to rollup
the popup!");
691     if (view) {
692       nsCOMPtr<nsIViewManager> viewManager;
693       view->GetViewManager(*getter_AddRefs(viewManager));
694       if (viewManager) { // the view manager can be null during widget teardown
....

it looks like we check the view and viewManager in the else block but didn't
check view and viewManager in the if block. should that be that way.
it looks like the reason the else block check that is becase
blakeross@telocity.com try to fix 90151 "Trunk/M092 topcrash @
nsMenuFrame::ActivateMenu,  ". Maybe we should do the samething in the if block.
cc blakeross@telocity.com
> ylong- still crash these day?

It doesn't crash on 04-10 trunk build /Mac 10.1.3, but when move the key up and
down for some drop down lists, still highlight/move up and down in category list
memu not the drop down list itself.
I cannot reproduce neither the crash nor the highlight issue. mark this as workforme
ylong- please file different bug about highlight if it is still a problem. 
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
With build ID 20022041712 (Moz. 1.0 rc1), Classic theme on Mac OS X 10.1.4, I
still get both the highlight issue and the crash when scrolling through pop-up
menus in preferences (cf. bug #130562). The crash is reproducable. It does
appear to be resolved when using the Modern theme, though.

Can I/shall I reopen the bug?
Yes, I still see both crash and highlighted problem on 04-18 branch build with
classic theme.  Re-open.

However I only see the highlighted but crash problem on latest trunk build on
same system.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I cannot reproduce the crash on 0429 branch build. ylong- can you still
reproduce this ?
Yes, still reproduce on 04-30 branch build / Mac10.1.4.
Pink, any chance you have enough cycles to look at this?  Joe is swamped with
plussed bugs....
never mind, Joe just noticed this involves focus being in the wrong pane. ->bryner.
Assignee: hewitt → bryner
Status: REOPENED → NEW
I'm fairly certain the crash will go away if I check in my patch for bug 129785
(nsMenuFrame.cpp, rev 1.223) on the branch.  Nominating for adt1.0.0 for
permission to do so.  This has been on the trunk since 4/10 with no regressions
reported because of it.  Very safe fix.
Status: NEW → ASSIGNED
Keywords: adt1.0.0
Note that the list will still not be keyboard-navigable, but that's a separate
issue and intentional behavior (read bug 64022).
Comment on attachment 81972 [details] [diff] [review]
patch against MOZILLA_1_0_0_BRANCH

This patch already got r=ben, sr=hyatt in bug 129785.
Attachment #81972 - Flags: superreview+
Attachment #81972 - Flags: review+
Resolving as fixed because this has been checked into the trunk.

pmac - Can you verify this is fixed without introducing any regressions?
Status: ASSIGNED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Let's get this one in after RC2. adt1.0.0- [adt2 RTM]
Keywords: adt1.0.0adt1.0.0-, topembed
Whiteboard: [adt2] → [adt2 RTM]
wfme both Modern and Classic themes with branch build ( OS 10.1.4,
2002-05-03-09-1.0.0) and trunk build (2002-05-03-08-TRUNK).
Status: RESOLVED → VERIFIED
This should still crash on the branch.
Brian, I still see no crash on the branch build  (2002-05-03-09-1.0.0) on os
10.1.4 by following the steps of how to reproduce from the reporter.
1. Go to Preferences dialog.
2. Select Navigator > Languages > 
3. Move up or down key to select the charset.
No crash at all.



Sorry, let me give more specific steps:

- Go to the Navigator/languages pref panel
- Click on the Default Character Coding dropdown at the bottom of the panel
- Press the up or down arrow key
Brian, thanks for your steps of how to reproduce, but unfortunately,
I couldn't reproduce the crash at all using today's branch build (mac os 10.1.4, 
branch build: 2002-05-06-05-1.0.0)

- Go to the Navigator/languages pref panel
- Click on the Default Character Coding dropdown at the bottom of the panel
  (ie; I choose Western (IBM-850) or Western (IS0- 8859-1)
- Press the up or down arrow key, it doesn't crash.
- I also press the "Move Up or Move Down" buttons. But, still it doesn't crash.

Yes, somehow I don't see the crash on 05-03 branch build neither, and the
up/down arrows works properly, not like before, the highlighted menu items was
wrong and would cause the crash.
of all the crash reports coming back for RC1 a very small pct. have user
comments related to actions in the pref pannels...   here is a breakdown.  any
thoughts on which stack signature(s) might be related to this crash.  this would
be a good one to get on the 1.0 branch but it could come after the endgame we
are in for RC2 since it looks like it might be lower impact.

 pref related user comments ====== 82
Bugstatus Legend:
      (LINK) = NEW, ASSIGNED or REOPENED
      (LINK) = WORKSFORME
      (LINK) = RESOLVED FIXED
      (LINK) = VERIFIED FIXED
      (LINK) = DUPLICATE

11 ntdll.dll (123097) (109139) (124003) (71909) (129093) (135789) (133857)
(120863) (82595) (91997) (97958) (105752) (118086) (132130) (135345) (138500)
(132689) (95179) (101586) (139296)
7 nsQueryInterface::operator() (100784) (114043) (56136) (114110)
5

4 nsHTMLReflowState::DetermineFrameType (124205)
3 nsGrid::FindRowsAndColumns
3 nsFormControlFrame::GetStyleSize
3 js_MarkGCThing (53123) (53438) (57066)
3 PL_DHashTableOperate (114292) (115672)
3 PL_CompareStrings
3 DOMGCCallback
2 nsAString::() (120637) (96563) (82332) (99569) (105619) (132067) (121055)
(84068) (106341)
2 libX11.so.6 (133633) (63353) (102208) (109723) (110559)
2 js_Interpret (132216) (98207) (106820) (97293) (132654)
1 operator (100784) (114043) (56136) (81728) (99510) (114110)
1 nsXULPrototypeScript::Compile (110404)
1 nsXULElement::CloneNode
1 nsWSRunObject::GetWSNodes()
1 nsWSRunObject::GetWSNodes
1 nsTreeSelection::FireOnSelectHandler()
1 nsTextFrame::PaintTextDecorations 
topembed minusing. please re-nominate if this impacts embedding applications.
Keywords: topembedtopembed-
Thanks Brian. I could able to reproduce the crash on Mac os 10.1.4, branch build
(2002-05-06-05-1.0.0) with the following steps:

- Go to the Navigator/languages pref panel (make sure it's hightlighted the
"Languages". Yesterday I couldn't reproduce the crash because it was
hightlighted inside the table of the "Languages in order of Preference".
- Click on the Default Character Coding dropdown at the bottom of the panel
- Press up and down arrow key (use keyboard please).
Current result: The browser quits and generates this error "The application 
                Netscape has unexpectedly quit". It doesn't give me a stacktrace.
a crash in an embedding app that uses xul prefs is topembed+, IMHO
Keywords: topembed-topembed+
It doesn't make sense to hold off on this till after rc2, any more than to hold
off on bug 129980 (trudelle pinged me for a= on that late last night as I was
retiring for the night -- I missed his IRC /msg).  I say we do both now.  Null
checks where we aren't papering over corrupt memory (where testing for null is
not enough) are not going to jeopardize rc2.

/be
Blocks: 136392
Comment on attachment 81972 [details] [diff] [review]
patch against MOZILLA_1_0_0_BRANCH

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #81972 - Flags: approval+
checked in on the branch.
Keywords: fixed1.0.0
changing to adt1.0.0+ to get off of the radar since this would have been +'d.
Keywords: adt1.0.0-adt1.0.0+
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: