User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100116 Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100116 Minefield/3.7a1pre The frequency of crashing is unpredictable. Whenever I switch tabs. I'll be always wary of whether minefield will crash or not. Even when I'm brought to the crash reporter restarting firefox sometimes will present me with another crash reporter prompt. But after a couple restarts it'll finally kick in gear and firefox will be resumed. I hadn't updated in about a month so when I finally updated it would seem a change within minefield has twisted something around. I do use an Add-on which is compatible, but it would seem it isn't AS compatible anymore. 20091204044732 is the last build that actually works with the add-on enabled. Reproducible: Sometimes Steps to Reproduce: 1.Minefield build 20100111043805 was the update after my month-long update sabbatical. 2.Tree Style Tab Build 0.8.2009122501 might have a problem with the 2010 minefield Updates. 3.Opening, switching or closing tabs will cause crashes. Actual Results: Random crashing and often improbable recovery of tabs. Expected Results: Switch to another tab. Close tab. Open tab. I am using the default theme. All other add-on's are disabled apart from Tree Style Tabs, because I do prefer to have my tab bar on the side.

Post crash ID: https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report

Signature nsDocAccessible::GetBoundsRect(nsRect&, nsIFrame**) UUID 48140901-7aab-458f-94b7-988612100116 Time 2010-01-16 12:46:05.184408 Uptime 1 Last Crash 2 seconds before submission Product Firefox Version 3.7a1pre Build ID 20100116042715 Branch 1.9.3 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info GenuineIntel family 6 model 23 stepping 6 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x4 User Comments Processor Notes Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll nsDocAccessible::GetBoundsRect accessible/src/base/nsDocAccessible.cpp:736 1 xul.dll nsAccessible::GetBounds accessible/src/base/nsAccessible.cpp:1119 2 xul.dll nsAccessibleWrap::accLocation accessible/src/msaa/nsAccessibleWrap.cpp:882 3 oleacc.dll AccWrap_Base::accLocation 4 oleacc.dll AccWrap_LocationEtcFix::accLocation 5 tiptsf.dll CARET::UpdateMSAAEditFieldState 6 tiptsf.dll CARET::UpdateEditFieldState 7 tiptsf.dll TabletShellProc 8 tiptsf.dll PrxDllCanUnloadNow 9 user32.dll __ClientCallWinEventProc 10 ntdll.dll ntdll.dll@0x100e5 11 user32.dll RealDefWindowProcW 12 user32.dll DefWindowProcW 13 user32.dll InternalCallWinProc 14 user32.dll UserCallWinProcCheckWow 15 user32.dll CallWindowProcAorW 16 user32.dll CallWindowProcW 17 xul.dll nsWindow::WindowProc widget/src/windows/nsWindow.cpp:3659 18 user32.dll InternalCallWinProc 19 user32.dll UserCallWinProcCheckWow 20 user32.dll DispatchClientMessage 21 user32.dll __fnDWORD 22 ntdll.dll ntdll.dll@0x100e5 23 xul.dll nsFocusManager::SetFocusInner dom/base/nsFocusManager.cpp:1153

I just tried to reproduce this with latest Minefield + Tree Style Tabs on both Linux and Windows XP. No crash. Might need better STR or it could be Windows 7 specific. Give a new profile a try if you haven't already: http://support.mozilla.com/en-US/kb/Managing+Profiles

dave: you're going to need some sort of accessibility agent. but this is a null pointer crash.

Creating a new profile did not work. It crashed on start up.

I think it should be x86.

Tried with latest mozilla-central with a11y on + Tree Style Tabs on OpenSolaris, it doesn't crash.

(In reply to comment #2) > http://crash-stats.mozilla.com/report/index/bp-48140901-7aab-458f-94b7-988612100116 it's strange because there is nothing to crash - http://hg.mozilla.org/mozilla-central/annotate/96dd0b76a3e1/accessible/src/base/nsDocAccessible.cpp#l736

(In reply to comment #3) > Crashing Thread > Frame Module Signature [Expand] Source > 0 xul.dll nsDocAccessible::GetBoundsRect > accessible/src/base/nsDocAccessible.cpp:736 In terms of the crashing line in source code is this: "if (parentDoc) {" or the preceding line: scrollPort = presShell->GetRootFrame()->GetRect() ? Maybe GetRootFrame is failing on startup because we don't have one yet?

Anyone able to reliably reproduce this bug willing to try this patch?

Tried reinstalling latest minefield and still running into crashes, but not as often.

Comment on attachment 422555 [details] [diff] [review] wild guess This is right. Let's get this in and see if it fixes the bug.

landed on 1.9.3 as http://hg.mozilla.org/mozilla-central/rev/ee032f1eddd2 Roc thanks for the vote of confidence. I'm not yet sure why this crasher started appearing though.

Appears I can reproduce this one in a completely different context: bp-aa899edf-4234-4e9f-9e5e-34ff52100122 and bp-eee40991-7cd6-46d0-b2bc-cdedd2100122

Latest Minefield update seems to have solved the crashing issue for now. Have been using Minefield without error for about an hour now. Will report back if any mishap occurs.

Thanks Joshua. I had similar feedback from shaver. Closing.

worksforme until the bug number with the fix is provided. Marco, can you reproduce the bug on Firefox 3.6?

Absolutely top drawer fellows. No problems to report.

Sorry for the spam, I missed the comment #15. Getting back fixed status.

No longer crashes for me in Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.3a1pre) Gecko/20100122 Minefield/3.7a1pre (.NET CLR 3.5.30729). The build from Wednesday did crash, but the fix went in after that build was made. Setting to VERIFIED since both Joshua and Shaver also report it's working for them now. Alexander, i could NOT reproduce this in 3.6.

(In reply to comment #22) > Alexander, i could NOT reproduce this in 3.6. Ok. Thank you guys for fixing and testing this!

Note I do see one crash stack with a build ID of 20100121041504 http://crash-stats.mozilla.com/report/index/110a9e46-ef2a-4deb-96e8-86c5d2100121 I don't know if this is a crash stat bug or what... but let's see what happens over the next few days. I'm encouraged by the fix verifications. (In reply to comment #20) > Absolutely top drawer fellows. And to you Joshua.

Sigh (the status change was accidental)