User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210 GranParadiso/3.0a7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7) Gecko/2007080210 GranParadiso/3.0a7 Sometimes I can get the browser to crash if I use text zoom while loading www.cnn.com. Doesn't seem to matter if it's a zoom in or out, and it won't happen consistently. Reproducible: Sometimes Steps to Reproduce: 1. Start browser which loads my bookmarks as it's homepage. 2. Click on the www.cnn.com bookmark. 3. Rapidly press Ctrl++ and/or Ctrl+- Actual Results: Crashes about 20% of the time, sometimes successfully does some zooms then crashes, sometimes crashes on the first key press. Occurs also in safe mode. Successfully repeated the crash about 5 times. Allowed two of them to be submitted via the crash report tool. Still working to get a consistent series of steps that can reliably reproduce, but those that I listed work about 20% of the time. Will also try on different web pages.

Okay, I've improved my reproducibility. I can now reliably get the browser to crash if I press Ctrl++ (or Ctrl+-) at about the same time as www.cnn.com attempts to load a pop-up. Might be a coincidence, or might not.

Dupe of bug 386584?

>> Dupe of bug 386584? Maybe, but I don't have quite same symptoms. I don't need to start from a new profile, and talkback DOES appear. It also appears to be a requirement that I press ctrl++ or ctrl+- while the page is loading (which wasn't mentioned in the 386584). If I wait until the page has finished loading, I can't get it to crash. Also of note, I tried on Firefox2 on my wife's computer and was not able to replicate.

You get talkback appear with GP alpha 7? Can you give us the TalkBackID of your crash then (or the breakpad ID if you get that)

I'm a little new to this system, but I think this is what you want: Crash ID: bp-81df1c87-46d2-11dc-a06a-001a4bd43ed6 You can view details of this crash at http://crash-stats.mozilla.com/report/index/81df1c87-46d2-11dc-a06a-001a4bd43ed6?date=2007-08-09-23 and Crash ID: bp-9bc52923-46d2-11dc-aa51-001a4bd43ef6 You can view details of this crash at http://crash-stats.mozilla.com/report/index/9bc52923-46d2-11dc-aa51-001a4bd43ef6?date=2007-08-09-23 BTW, attempted earlier today, CNN did not attempt to do a pop-up and I still got it to crash. Also followed the procedure to duplicate bug 386584, and I have to say that the way it crashed seemed very similar to my instance (even if the path to get there is different).

Perfect. The first bpid suggests this bug is a dupe of bug 389744. The second doesn't look very useful to my eyes.

(Since we haven't decided how long Breakpad reports will be kept around...) Stack of Crashing Thread frame signature source 0 nsPropertyTable::PropertyList::Equals(unsigned short, nsIAtom*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\content\base\src\nspropertytable.cpp:85 1 nsPropertyTable::GetPropertyListFor(unsigned short, nsIAtom*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\content\base\src\nspropertytable.cpp:295 2 nsPropertyTable::GetPropertyInternal(nsPropertyOwner, unsigned short, nsIAtom*, int, unsigned int*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\content\base\src\nspropertytable.cpp:190 3 nsPropertyTable::GetProperty(nsPropertyOwner, nsIAtom*, unsigned int*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\content\base\src\nspropertytable.h:113 4 nsIFrame::GetProperty(nsIAtom*, unsigned int*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsframe.cpp:5700 5 nsIFrame::GetView() e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsframe.cpp:3446 6 nsFrame::Destroy() e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsframe.cpp:632 7 nsSubDocumentFrame::Destroy() e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsframeframe.cpp:600 8 nsFrameList::DestroyFrame(nsIFrame*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsframelist.cpp:162 9 nsAbsoluteContainingBlock::RemoveFrame(nsIFrame*, nsIAtom*, nsIFrame*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsabsolutecontainingblock.cpp:127 10 nsBlockFrame::RemoveFrame(nsIAtom*, nsIFrame*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\generic\nsblockframe.cpp:4985 11 nsFrameManager::RemoveFrame(nsIFrame*, nsIAtom*, nsIFrame*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\base\nsframemanager.cpp:690 12 nsCSSFrameConstructor::ContentRemoved(nsIContent*, nsIContent*, int, int) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\base\nscssframeconstructor.cpp:9588 13 nsCSSFrameConstructor::RecreateFramesForContent(nsIContent*) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\base\nscssframeconstructor.cpp:11128 14 nsCSSFrameConstructor::ProcessRestyledFrames(nsStyleChangeList&) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\base\nscssframeconstructor.cpp:9961 15 nsPresContext::ClearStyleDataAndReflow() e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\base\nsprescontext.cpp:668 16 DocumentViewerImpl::SetTextZoom(float) e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\layout\base\nsdocumentviewer.cpp:2687 17 NS_InvokeByIndex_P e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:101 18 AutoJSSuspendRequest::SuspendRequest() e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcprivate.h:3312 19 js_InternalInvoke e:\builds\tinderbox\fx-mozilla1.9-release\winnt_5.2_depend\mozilla\js\src\jsinterp.c:1428

Is this still an issue in current trunk build?

> Is this still an issue in current trunk build? Nope. I can no longer reproduce the bug with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100304 Minefield/3.0a9pre Which I assume is the current trunk build (still learning the system).

Kendall, thank you. That is indeed the current trunk build (you're learning quickly). So I'm marking this worksforme, probably fixed by bug 389744, though.