Steps to reproduce: 1) Open an email with a large CC list. 2) Click Reply All 3) Position the mouse over the recipient list 4) use the scroll wheel to scroll down 5) scroll up 6) scroll down again 7) poof. Using the scroll bar does not seem to affect it, it only happens when you use the scroll wheel. Relevant talkback IDs: 2005092906: TB9906699Z TB9906647H 2005093005: TB9926822Z TB9927354H
Created attachment 198103 [details] CrashReporter log CrashReporter crash log, since it's sometimes more useful than the talkback stack traces.
Couldn't reproduce on 10.4.2, which Dave is also running. My QuickDraw library is newer than his. The QD library was updated in Security Update 2005-8.
Summary: QD.186.1.0 + 0xb0b8 (0x916a60b8) fa947574 crash when scrolling in recipient list → QD.186.1.0 + 0xb0b8 (0x916a60b8) fa947574 crash when scrolling in recipient list
Dave also managed to crash this at TB9930320Y. I am now able to reproduce. I'll investigate.
Summary: QD.186.1.0 + 0xb0b8 (0x916a60b8) fa947574 crash when scrolling in recipient list → Crash [@ InternalColor2Index() ] when scrolling in recipient list
This was broken at least as far back as 091507. There are a variety of different stack traces that this will crash with. Something is being destroyed. Looks like the frames that are scrolled out of view. The build IDs aren't strongly related to the crashes, they're only the builds that produced certain crashes. 100105, 092209, and 091507 crash in DispatchEventToHandlers . nsMacWindow::ScrollEventHandler . SetGWorld 092805 is an interesting crash in DispatchEventToHandlers . nsMacWindow::ScrollEventHandler .. nsListBoxBodyFrame::InternalPositionChanged . nsListBoxBodyFrame::DestroyRows .. nsFrameList::DestroyFrames . nsContainerFrame::Destroy . nsFrame::Destroy . nsView::~nsView . nsView::DropMouseGrabbing 092607 and 091905 are also interesting, similar to the above crash but after the nsView destructor, nsBaseWidget::Release . nsMacWindow::~nsMacWindow . (system window destruction functions)
*** Bug 317873 has been marked as a duplicate of this bug. ***
Dave, do you still see this? bug 331937, which doesn't seem related, is only bug I find with SetPortRGBForeColor in the stack (SetPortRGBForeColor is second in your stack)
Assignee: mscott → nobody
nope. And I remember seeing it listed as getting fixed in the Rumbling Edge report at some point, too, so was this supposed to be a dupe?
dunno about the dupe. => WFM - someone can look for the dupe if they wish
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ InternalColor2Index() ]
You need to log in before you can comment on or make changes to this bug.