432467 - firefox segfaults in plone kupu editor [@ nsDocAccessible::FlushPendingEvents], on Tablet PC [@arena_dalloc_small] (steps to reproduce in comment #26)

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Matěj Cepl]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Build Identifier: firefox-3.0-0.60.beta5.fc9.x86_64 xulrunner-1.9-0.60.beta5.fc9.x86_64

(originally filed as Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=445199)

Core was generated by `/usr/lib64/firefox-3.0b5/firefox'.
Program terminated with signal 11, Segmentation fault.

#4  0x000000335b3e68f0 in nsVoidArray::EnumerateForwards (this=<value optimized
out>, aFunc=<value optimized out>, aData=<value optimized out>) at
nsVoidArray.cpp:678
678	      running = (*aFunc)(mImpl->mArray[index], aData);
(gdb) list
673	
674	  if (mImpl)
675	  {
676	    while (running && (++index < mImpl->mCount))
677	    {
678	      running = (*aFunc)(mImpl->mArray[index], aData);
679	    }
680	  }
681	  return running;
682	}
#3  0x000000335b3e3e80 in ReleaseObjects (aElement=<value optimized out>) at
nsCOMArray.cpp:151
151	    NS_IF_RELEASE(element);
Current language:  auto; currently c++
(gdb) list
146	// useful for destructors
147	PRBool
148	ReleaseObjects(void* aElement, void*)
149	{
150	    nsISupports* element = static_cast<nsISupports*>(aElement);
151	    NS_IF_RELEASE(element);
152	    return PR_TRUE;
153	}
154	
155	void
(gdb) down
#2  <signal handler called>
Current language:  auto; currently c
(gdb) list
156	nsCOMArray_base::Clear()
157	{
158	    mArray.EnumerateForwards(ReleaseObjects, nsnull);
159	    mArray.Clear();
160	}
161	
(gdb) down
#1  0x000000335ac268cd in nsProfileLock::FatalSignalHandler (signo=<value
optimized out>) at nsProfileLock.cpp:212
212	            raise(signo);


Comment #1 From Martin Stransky ([e-mail]) 	on 2008-05-05 09:26 EST 	[reply] 	Private

Can you please attach steps how to reproduce it?


Comment #2 From Harald Hoyer ([e-mail]) 	on 2008-05-05 10:20 EST 	[reply] 	Private

1. create a new article in plone using the internal kupu editor.
2. write some text
3. click on ["html"]
4. boom


Comment #3 From Matej Cepl ([e-mail]) 	on 2008-05-05 16:19 EST 	[reply] 	Private

(In reply to comment #2)
> 1. create a new article in plone using the internal kupu editor.
> 2. write some text
> 3. click on ["html"]
> 4. boom

Is there some internal (or publicly accessible external) instance of plone?


Comment #4 From Harald Hoyer ([e-mail]) 	on 2008-05-05 22:25 EST 	[reply] 	Private

if you ping me on IRC, I can give you temporary access to my instance.


Comment #5 From Harald Hoyer ([e-mail]) 	on 2008-05-06 00:45 EST 	[reply] 	Private

start firefox on x86_64:

login on:
https://test.harald-hoyer.de/login_form

User: test
PW: testit

go to:
https://test.harald-hoyer.de/personal/blog/augeas/edit

click in the big editor form. click on "HTML" in the editor toolbar.


Comment #6 From Martin Stransky ([e-mail]) 	on 2008-05-06 04:11 EST 	[reply] 	Private

Hm, the provided testcase works fine for me (no crash). I have FF3 Beta5 with
internal cairo.


Comment #7 From Martin Stransky ([e-mail]) 	on 2008-05-06 04:11 EST 	[reply] 	Private

on x86_64.


Comment #8 From Harald Hoyer ([e-mail]) 	on 2008-05-06 04:36 EST 	[reply] 	Private

I'll retry with no plugins, fresh user. maybe I can pin it down to s.th.


Comment #9 From Harald Hoyer ([e-mail]) 	on 2008-05-06 04:45 EST 	[reply] 	Private

hmm, as a fresh user, no problem.

moving away .mozilla with my main user does not change anything. still segfault.


Comment #10 From Martin Stransky ([e-mail]) 	on 2008-05-06 04:47 EST 	[reply] 	Private

Try the safe mode (firefox -safe-mode)


Comment #11 From Harald Hoyer ([e-mail]) 	on 2008-05-06 05:02 EST 	[reply] 	Private

$ firefox -safe-mode
/usr/lib64/firefox-3.0b5/run-mozilla.sh: line 131: 27408 Segmentation fault    
 "$prog" ${1+"$@"}


Comment #12 From Harald Hoyer ([e-mail]) 	on 2008-05-06 05:27 EST 	[reply] 	Private

#0  0x000000334ec0ebeb in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
42				 sig);
Missing separate debuginfos, use: debuginfo-install keyutils.x86_64
(gdb) bt
#0  0x000000334ec0ebeb in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#1  0x000000335ac268cd in nsProfileLock::FatalSignalHandler (signo=<value
optimized out>) at nsProfileLock.cpp:212
#2  <signal handler called>
#3  0x00000000046644f0 in ?? ()
#4  0x000000335b386870 in nsDocAccessible::FlushPendingEvents (this=<value
optimized out>) at nsDocAccessible.cpp:1640
#5  0x000000335b418ee2 in nsTimerImpl::Fire (this=<value optimized out>) at
nsTimerImpl.cpp:400
#6  0x000000335b418f49 in nsTimerEvent::Run (this=<value optimized out>) at
nsTimerImpl.cpp:490
#7  0x000000335b416a9e in nsThread::ProcessNextEvent (this=<value optimized
out>, mayWait=<value optimized out>, result=<value optimized out>) at
nsThread.cpp:510
#8  0x000000335b3e82f6 in NS_ProcessNextEvent_P (thread=<value optimized out>,
mayWait=<value optimized out>) at nsThreadUtils.cpp:227
#9  0x000000335b36010d in nsBaseAppShell::Run (this=<value optimized out>) at
nsBaseAppShell.cpp:170
#10 0x000000335b2235bd in nsAppStartup::Run (this=<value optimized out>) at
nsAppStartup.cpp:181
#11 0x000000335ac1f73b in XRE_main (argc=<value optimized out>, argv=<value
optimized out>, aAppData=<value optimized out>) at nsAppRunner.cpp:3154
#12 0x0000000000401665 in __gxx_personality_v0 () at
../../../../libstdc++-v3/libsupc++/eh_personality.cc:363
#13 0x000000334e01e32a in __libc_start_main (main=<value optimized out>,
argc=<value optimized out>, ubp_av=<value optimized out>, init=<value optimized
out>, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=Could not find the frame base for "__libc_start_main".
) at libc-start.c:220
#14 0x0000000000401159 in __gxx_personality_v0 () at
../../../../libstdc++-v3/libsupc++/eh_personality.cc:363


Comment #13 From Harald Hoyer ([e-mail]) 	on 2008-05-06 05:29 EST 	[reply] 	Private

(gdb) up
#4  0x000000335b386870 in nsDocAccessible::FlushPendingEvents (this=<value
optimized out>) at nsDocAccessible.cpp:1640
1640	  NS_RELEASE_THIS(); // Release kung fu death grip
Current language:  auto; currently c++
(gdb) up
#5  0x000000335b418ee2 in nsTimerImpl::Fire (this=<value optimized out>) at
nsTimerImpl.cpp:400
400	      callback.c(this, mClosure);
(gdb) up
#6  0x000000335b418f49 in nsTimerEvent::Run (this=<value optimized out>) at
nsTimerImpl.cpp:490
490	  timer->Fire();
(gdb) up
#7  0x000000335b416a9e in nsThread::ProcessNextEvent (this=<value optimized
out>, mayWait=<value optimized out>, result=<value optimized out>) at
nsThread.cpp:510
510	    event->Run();
(gdb) up
#8  0x000000335b3e82f6 in NS_ProcessNextEvent_P (thread=<value optimized out>,
mayWait=<value optimized out>) at nsThreadUtils.cpp:227
227	  return NS_SUCCEEDED(thread->ProcessNextEvent(mayWait, &val)) && val;
(gdb) up
#9  0x000000335b36010d in nsBaseAppShell::Run (this=<value optimized out>) at
nsBaseAppShell.cpp:170
170	    NS_ProcessNextEvent(thread);
(gdb) up
#10 0x000000335b2235bd in nsAppStartup::Run (this=<value optimized out>) at
nsAppStartup.cpp:181
181	    nsresult rv = mAppShell->Run();
(gdb) up
#11 0x000000335ac1f73b in XRE_main (argc=<value optimized out>, argv=<value
optimized out>, aAppData=<value optimized out>) at nsAppRunner.cpp:3154
3154	          rv = appStartup->Run();
(gdb) up
#12 0x0000000000401665 in __gxx_personality_v0 () at
../../../../libstdc++-v3/libsupc++/eh_personality.cc:363
363			      struct _Unwind_Context *context)


Comment #14 From Martin Stransky ([e-mail]) 	on 2008-05-06 05:49 EST 	[reply] 	Private

Try to turn off gnome accesibility. Does it help?


Comment #15 From Harald Hoyer ([e-mail]) 	on 2008-05-06 06:09 EST 	[reply] 	Private

rofl.. yes :)

Reproducible: Always

Steps to Reproduce:
1.turn the accessibility support on
2. create a new article in plone using the internal kupu editor.
3. write some text
4. click on ["html"]
5. boom
Actual Results:  
crash

Expected Results:  
no crash

Comment 1

[timeless]

if you're going to be filing bugs into our bugzilla, please:
. try to only copy meaningful comments
. include signature lines in your summaries when you file
. for crashes please select severity: critical
. for bugs in core, please file then in core instead of in firefox
. please select version: Trunk if you're using trunk (atm 3.0betas are trunk)
. please select version: {whatever is appropriate} if you aren't.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

I can confirm the crash. Here is a backtrace from debug build:

#0  0x00002aaaac7a0a2e in ReleaseObjects (aElement=0x2aaabc143ce0) at nsCOMArray.cpp:151
#1  0x00002aaaac7a63cf in nsVoidArray::EnumerateForwards (this=0x2aaabc143e20, aFunc=0x2aaaac7a0a04 <ReleaseObjects>, 
    aData=0x0) at nsVoidArray.cpp:678
#2  0x00002aaaac7a0a67 in nsCOMArray_base::Clear (this=0x2aaabc143e20) at nsCOMArray.cpp:158
#3  0x00002aaaac6f9347 in nsCOMArray<nsIAccessibleEvent>::Clear (this=0x2aaabc143e20)
    at ../../../dist/include/xpcom/nsCOMArray.h:217
#4  0x00002aaaac6f2ef0 in nsDocAccessible::FlushPendingEvents (this=0x2aaabc143cf0) at nsDocAccessible.cpp:1639
#5  0x00002aaaac6ef7df in nsDocAccessible::FlushEventsCallback (aTimer=0x2aaabc235190, aClosure=0x2aaabc143d98)
    at nsDocAccessible.cpp:1655
#6  0x00002aaaac811266 in nsTimerImpl::Fire (this=0x2aaabc235190) at nsTimerImpl.cpp:400
#7  0x00002aaaac81147a in nsTimerEvent::Run (this=0x2aaabc2c1b50) at nsTimerImpl.cpp:490
#8  0x00002aaaac80bd70 in nsThread::ProcessNextEvent (this=0x67d390, mayWait=1, result=0x7fffed5639bc) at nsThread.cpp:510
#9  0x00002aaaac7a998c in NS_ProcessNextEvent_P (thread=0x67d390, mayWait=1) at nsThreadUtils.cpp:227
#10 0x00002aaaac6aa9bc in nsBaseAppShell::Run (this=0x83ce90) at nsBaseAppShell.cpp:170
#11 0x00002aaaac46c0e6 in nsAppStartup::Run (this=0x94bdd0) at nsAppStartup.cpp:181
#12 0x00002aaaab8f91be in XRE_main (argc=1, argv=0x7fffed5675c8, aAppData=0x626e60) at nsAppRunner.cpp:3154
#13 0x0000000000401785 in main (argc=1, argv=0x7fffed5675c8) at nsXULStub.cpp:348
#14 0x00000038fc21e074 in __libc_start_main () from /lib64/libc.so.6
#15 0x0000000000400f39 in _start ()

aElement doesn't seem to be valid:

#0  0x00002aaaac7a0a2e in ReleaseObjects (aElement=0x2aaabc143ce0) at nsCOMArray.cpp:151
(gdb) p aElement 
$5 = (void *) 0x2aaabc143ce0
(gdb) p* element  
$6 = {_vptr.nsISupports = 0x5}


(gdb) up
#1  0x00002aaaac7a63cf in nsVoidArray::EnumerateForwards (this=0x2aaabc143e20, aFunc=0x2aaaac7a0a04 <ReleaseObjects>, 
    aData=0x0) at nsVoidArray.cpp:678
(gdb) info locals 
index = 0
running = 1
(gdb) p mImpl->mCount
$12 = 10922

Comment 3

[Martin Stránský [:stransky] (ni? me)]

(gdb) f
#4  0x00002aaaac6f2ef0 in nsDocAccessible::FlushPendingEvents (this=0x2aaabc143cf0) at nsDocAccessible.cpp:1639
(gdb) info locals 
length = 0
presShell = {mRawPtr = 0x0}

Comment 4

[Martin Stránský [:stransky] (ni? me)]

The  mEventsToFire.Clear(); NS_RELEASE_THIS(); combo is called twice for the same nsDocAccessible instance. First from:

#0  nsDocAccessible::Shutdown (this=0x3046680) at nsDocAccessible.cpp:583
#1  0x00002aaaac6e6e2e in nsAccessNode::GetPresShell (this=0x3046680) at nsAccessNode.cpp:347
#2  0x00002aaaac6f247a in nsDocAccessible::FlushPendingEvents (this=0x3046680) at nsDocAccessible.cpp:1494

and then from nsDocAccessible::FlushPendingEvents itself.

Comment 5

[Ginn Chen]

Good catch, thank you.

Perhaps we should add a bool member to record whether the kung fu death grip is released.

Comment 6

[Ginn Chen]

I don't have a chance to reproduce the crash stack like comment #2.

I tried kupu editor test page.
http://www.craic.com/oreilly/kupu/kupu/common/kupu.html

I got a lot ASSERTs of a11y module with debug build, and got several different crash stacks with release build, but none of them are crashed in a11y module.
But I think it's related to a11y, because I can't crash Firefox with a11y off. 

Comment 7

[Ginn Chen]

Finally I got it reproduced. Taking.

Comment 8

[Ginn Chen]

Attachment: patch

Make sure we're not released twice.

Comment 9

[Aaron Leventhal]

Ginn, can you explain what happens? How do we end up in Shutdown() while in the middle of flushing pending events?

 

Comment 10

[Ginn Chen]

1506 NS_IMETHODIMP nsDocAccessible::FlushPendingEvents()
1507 {
1508   PRUint32 length = mEventsToFire.Count();
1509   NS_ASSERTION(length, "How did we get here without events to fire?");
1510   nsCOMPtr<nsIPresShell> presShell = GetPresShell();
1511   if (!presShell)
1512     length = 0; // The doc is now shut down, don't fire events in it anymore

Calling GetPresShell() may cause the doc be shut down.
See comment #4.

Comment 11

[Aaron Leventhal]

Then should we also change the event loop in FlushPendingEvents() to see if the doc is shut down, and if so, exit early?

Comment 12

[Mike Schroepfer]

Aaron can I get a priority/risk assessment for this bug? We are mostly locked down for final release and would only take showstoppers at this point.

Comment 13

[Mike Schroepfer]

Only taking showstopper issues at this point.  If this is one of those please re-nom with why.

Comment 14

[Aaron Leventhal]

Comment on attachment 320109 [details] [diff] [review]
patch

I don't see anything risky in the patch, and it's always good to keep working on a11y crashes. We don't get as much testing coverage as other stuff does but we do try to deal with our crash reports. It's hard to say how much this will happen for Firefox 3 users.

Comment 15

[alexander :surkov (:asurkov)]

Ginn, we can fail at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/accessible/src/base/nsDocAccessible.cpp&rev=1.243#1628. It would mean we won't release kung fu grip, right?

Comment 16

[alexander :surkov (:asurkov)]

Comment on attachment 320109 [details] [diff] [review]
patch

r=me

Comment 17

[alexander :surkov (:asurkov)]

(In reply to comment #15)
> Ginn, we can fail at
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/accessible/src/base/nsDocAccessible.cpp&rev=1.243#1628.
> It would mean we won't release kung fu grip, right?
> 

Ginn, would you like to fix this in the bug?

Comment 18

[Ginn Chen]

Attachment: patch v2

Addressing surkov's comment.

Comment 19

[alexander :surkov (:asurkov)]

Comment on attachment 320499 [details] [diff] [review]
patch v2

r=me, asking approval, see comment #14

Comment 20

[Marco Zehe (:MarcoZ)]

Requesting that this be considered should we need a respin for RC2. Since I don't know of a better way, I put something to that effect in the status whiteboard.

Comment 21

[Mike Schroepfer]

added [RC2?] to whiteboard to make sure it is considered if there is an RC2

Comment 22

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Not for RC2, can take for 1.9.0.1 if it proves out -- please get a test up as soon as you can.

Comment 23

[Marco Zehe (:MarcoZ)]

Ginnk Surkov, can you work on getting a Mochitest testcase up for this? Thanks!

Comment 24

[Ginn Chen]

Macro, I don't know how to write a mochitest for this.

Surkov, do you have an idea? 

Comment 25

[alexander :surkov (:asurkov)]

That's hard to think of mochitest for this but in any way for this we could try to reproduce user actions in JS. Ginn, could you please put your steps to reproduce the bug?

Comment 26

[Ginn Chen]

My reproduce steps:

1) Open Firefox 3 with GNOME a11y enabled and keep accerciser running behind
2) Open kupu editor test page
http://www.craic.com/oreilly/kupu/kupu/common/kupu.html
3) Set focus to editor box, press Ctrl+A to select all the content, press delete
4) Find the "edit HTML code" button in kupu toolbar, click it.
5) click the "edit HTML code" button again to switch back.
6) repeat step 4)-5) several times, Firefox should not be hang or crash.

Note: If you're using a release build, the stack could be anywhere that calling free().

Comment 28

[(not currently active) Ted Mielczarek]

Looks like this affects all Tablet PC users too, from bug 436375.

Comment 29

[(not currently active) Ted Mielczarek]

And by "affects" I mean "Tablet PC users are crashing randomly".

Comment 30

[Martijn Wargers (dead)]

Bug 418142 is about the same issue, I guess?

Comment 31

[(not currently active) Ted Mielczarek]

Martijn: does the build with the patch applied fix your crashes?

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Renominating: bug 436375 implies that this particular bug nets out to "user on tablet PCs will have a pretty bad experience with Firefox 3". Options are:

 - relnote
 - respin

Comment 34

[Martijn Wargers (dead)]

(In reply to comment #31)
> Martijn: does the build with the patch applied fix your crashes?

You mean the build with the patch from bug 436375, comment 23?
Yes, tat seems to fix the crash.

I've marked bug 418142 now as a duplicate of this bug.
That bug has minimal testcases attached, btw.

I'm glad this bug is getting fixed, I was hitting this kind of crash all the time while testing with accessibility.

Comment 35

[Mike Beltzner [:beltzner, not reading bugmail]]

The bug will be fixed, though it's unclear if it will cause a respin.

It would help if we could get:
  - an understanding of what code is being called by Windows Tablet PCs
  - a rough estimate of how many crashes we're seeing from this
  - a rough understanding of marketshare for Tablet PCs

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

From bug 434752 comment 10:

> oh, right, the input panel. i knew it was used somewhere. thanks!
> 
> http://msdn.microsoft.com/en-us/library/ms818403.aspx
> http://msdn.microsoft.com/en-us/library/ms811573.aspx

Marco says that he can't reproduce this crash with the samples in bug 418142 provided by mw22.

Looking through what this patch fixes, I heavily suspect that it was caused by bug 403260, but that's just an allegation at this point :)

Comment 37

[Marco Zehe (:MarcoZ)]

The top crasher with FlushPendingEvents somewhere in the top 10 frames is this one, with a total of 138 in the last 4 weeks:
http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=stack&query_type=contains&product=Firefox&platform=windows&version=Firefox%3A3.0&branch=1.9&signature=nsCOMPtr_base%3A%3A~nsCOMPtr_base()&query=FlushPendingEvents&range_value=4

All others are below 20 and with varying signatures.

Comment 38

[(not currently active) Ted Mielczarek]

We may be able to look for crash reports whose module list contains "tiptsf.dll". This seems to be the input panel module. This may get more than we want, but since people are crashing randomly, it seems pretty likely that their crashes would be related to this.

Comment 39

[olistrut]

(In reply to comment #35)
> It would help if we could get:
>   - a rough understanding of marketshare for Tablet PCs

I don't have access to the full reports, but according to an IDC report quoted by channelinsider, Tablet PCs had a market share of more than 7% of the overall mobile PC market (http://www.channelinsider.com/c/a/Tech-Analysis/Time-to-Talk-About-Tablet-PCs/) and notebooks represent roughly 30% of the overall PC market (http://news.cnet.com/Notebooks-continue-shipment-gains/2100-1044_3-5070313.html).

So this bug should roughly affect 7%*30%=2.1% percent of the user base. And it hits them hard: I have seen days with more than 20 random crashes on my tablet PC.

Comment 40

[Marco Zehe (:MarcoZ)]

Fix has been checked into mozilla-central in changeset 263749849d0b. Leaving bug open until we check this into the 1.9.0 branch.

Comment 41

[Marcia Knous [:marcia]]

We received the IBM tablet PC from Toronto and I installed it in the QA lab for testing. It is running Windows XP PC Tablet Edition 2005 with SP 2. I was not able to reproduce the issue cited in this bug with RC2.

Comment 42

[Marco Zehe (:MarcoZ)]

Comment on attachment 320499 [details] [diff] [review]
patch v2

Requesting that this be allowed to land for 3.0.1:

- It already has blocking status.
- It has been determined that this fixes a big heap of problems like bug 436375 for tablet PCs.
- The testcase in bug 418142 no longer crashes with this patch in place.

Question: Is there a way to turn that testcase into a regular mochitest? Or should these not be mochitests since they are strictly spoken not unit tests but a crash test instead?

Comment 44

[(not currently active) Ted Mielczarek]

Marco: we have a set of crash tests that gets run on the unit test boxes:
http://developer.mozilla.org/en/docs/Mozilla_automated_testing#Crash_tests

They're set up just like reftests, but the point is that they should run without crashing. If this testcase can reproduce the crash without a11y enabled, then it should be easy to make a crash test from it.

Comment 45

[Marco Zehe (:MarcoZ)]

(In reply to comment #44)
> If this testcase can reproduce the crash without a11y
> enabled, then it should be easy to make a crash test from it.

No, that's the whole point, without a11y, this crash will never happen. That's why mostly people using a Tablet PC see this, and hardly any others. Tablet PC uses a11y stuff and thus enables this faulty code.

Comment 46

[Mike Beltzner [:beltzner, not reading bugmail]]

Although, confusingly, Marcia's report in comment 41 indicates that it isn't affecting all Tablet PC users. Do we know if it's only Tablet PC w/Vista?

Marco: this landed on central; are we seeing any other regressions or problems with the patch?

Until we know that, I'm moving this back down to nominated for 1.9.0.1, but wanted on 1.9.0.x; I'll be looking at patch approvals later tonight or tomorrow.

Comment 47

[Marco Zehe (:MarcoZ)]

(In reply to comment #46)
> Although, confusingly, Marcia's report in comment 41 indicates that it isn't
> affecting all Tablet PC users. Do we know if it's only Tablet PC w/Vista?

No, it's also Tablet PCs running XP, see bug 436375, and that reporter's machine was completely fixed once he ran a custom build Ted made for him with this patch applied.

> Marco: this landed on central; are we seeing any other regressions or problems
> with the patch?

No, not as far as I can see. I've been running both nightlies for the past days, and also did various test development on builds I made from Central, and am not seeing any regressions.

I'd also give you some info about crashes reported on 3.1a1pre (if any), if crash-stats sent me something, but it is in a bad mood today.

Comment 48

[Marco Zehe (:MarcoZ)]

Setting bug to fixed in accordance to rules laid out by Sam in mozilla.dev.planning. Landed on mozilla-central a few weeks ago already, see comment #40.

Comment 49

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 320499 [details] [diff] [review]
patch v2

a=beltzner

Comment 50

[Marco Zehe (:MarcoZ)]

Checking in accessible/src/base/nsDocAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsDocAccessible.cpp,v  <--  nsDocAccessible.cpp
new revision: 1.245; previous revision: 1.244
done
Checking in accessible/src/base/nsDocAccessible.h;
/cvsroot/mozilla/accessible/src/base/nsDocAccessible.h,v  <--  nsDocAccessible.h
new revision: 1.80; previous revision: 1.79
done

Comment 51

[Marcia Knous [:marcia]]

Can the reporter or someone who was able to reproduce the crash on tablet PC please download the nightly and confirm that this fixes the crash? I haven't been able to reproduce the issue on the tablet PC we have in the QA lab.

Comment 52

[Henry]

I no longer have this issue with version 3.1a1pre

Comment 53

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
by using the testcases in bug 418142.
I used to crash with those in Firefox 3.0, but not anymore, with the Firefox3.0.1 build.

Comment 56

[Marco Zehe (:MarcoZ)]

This landed on m-c in June of 2008 when that was still 1.9.1, and should've been marked verified ages ago. Sorry!