291549 - [regression] Crashes or hangs randomly when opening new links, closing tabs, opening new links in tabs [@ nsAccessNode::GetDocShellTreeItemFor] [@ nsAccessibilityService::OnStateChange]

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[William Price]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+

Ok, shortly after the 20050412 build was released I started noticing this
problem;  I can't remember if it was exactly that build, but it was close.

For the last week or so (and I've been trying multiple new builds) I get random
crashes when doing some very trivial tasks like middle-clicking links to open in
a new background tab, or closing a tab, or simply submitting a form or visiting
a link in the current tab.

It's completely random and I haven't been able to narrow down any common
factors; it's not site dependent.  Nor is it dependent on a particular action;
it seems that anything requiring a page load has the opportunity to crash the
browser.  The number of tabs doesn't matter, either, I've had it happen anywhere
from 1 tab to 8.


Additionally, sometimes the "crash" is just a hang when loading the page... the
throbber stops spinning, but all the other UI is mostly responsive.  If I try to
close the window, it asks me to confirm.  If I switch tabs, I see the other page
though I believe the URL and title bars don't update their content after the
switch (I'll have to double-check that.)  Other UI buttons appear to respond,
but do not actually execute their function (i.e. refresh doesn't do anything).
When it hangs like this instead of immediately crashing it will crash as soon as
I close the window.

Surely I'm not the only one with this problem.  I at first figured it was a
profile thing, but I just created a new profile with this build and it still
happened eventually.

Reproducible: Always

Steps to Reproduce:
Randomly occurs when doing one of the following:

1. Middle-click link to open in new tab
2. Close an existing tab
3. Submit form or follow a link in the current tab

Actual Results:  
Hang, with semi-responsive UI, until window is closed in which case the program
immediately dumps out to Talkback.

Or, immediate crash to Talkback.

Expected Results:  
Desired behavior, no crash, 'nuff said.

Here's a stack of Talkback IDs.  I can provide the new profile I created as an
attachment if anyone thinks it would be of use.

TB5288645M, TB5288601X, TB5288554Y, TB5280366Q, TB5223069Q, TB5222474Y

Comment 1

[William Price]

keywords -> regression, crash, hang

Comment 2

[Matthias Versen [:Matti]]

Do you see this if you run firefox in the safemode ?
(just to be sure that this is not injected by an extension)

Comment 3

[William Price]

(In reply to comment #2)
> Do you see this if you run firefox in the safemode ?
> (just to be sure that this is not injected by an extension)
> 

I saw this in a completely new profile -- no extensions installed.
I figured this was a better test than "disabling" my normal extensions via
safe-mode; I can try safe mode again if you think it would make a difference.

Comment 4

[William Bumgarner [:zsinj]]

Every Talkback has the same:

Stack Signature: nsAccessNode::GetDocShellTreeItemFor
Trigger Reason: Access violation
Source File, Line No.:
c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/accessible/src/base/nsAccessNode.cpp,
line 501

Comment 5

[William Bumgarner [:zsinj]]

William Price - Also, try updating to the most recent nightly build to date.
http://www.mozilla.org/developer/

I have not yet run into this crash/hang.

Comment 6

[William Price]

(In reply to comment #5)
> William Price - Also, try updating to the most recent nightly build to date.
> http://www.mozilla.org/developer/
> 
> I have not yet run into this crash/hang.

It concerns me that I'm the only one crashing; I thought I was on a newer build
than 20050417 when I wrote that. Last night I installed 20050422 and still run
into this problem randomly on my existing profile as well as a clean one.

Toshiba Portege 3500 tablet, PIIIm 1.3ghz
WinXP SP2 Tablet Edition

Perhaps it's something w/ the tablet OS modifications?

Comment 7

[William Price]

Okay, I'm upgrading this from a shot in the dark to stumbling around in twilight...

As is logical, the Tablet Edition of XP most definitely uses the accessibility
APIs to hook in the pen and speech input capabilities built-in to the OS.

http://msdn.microsoft.com/library/en-us/tpcsdk10/lonestar/whitepapers/speech/tbconexposingscreenelements.asp

The accessibility-related changes that the Talkback report indicates, combined
with the MSDN article, likely point to why *I* am having trouble vs. others not
on the Tablet Edition.  I did notice that something changed because I stopped
getting popup-TIP options on the input controls in Firefox.  Additionally, I
don't know if this affects others  using normal screen readers; if not, it could
be on the speech side.

Enough conjecture for now. Anyone out there with a tablet care to confirm? 
Please.  :-)

Comment 8

[Jay Patel [:jay]]

Adding topcrash+ keyword so that we get this fixed asap.  Looks like a recent
checkin by Aaron L. might have caused this regression.

Looks like he's out until May 5, anyone else that can take a look at this before
then?

Comment 9

[Matthias Versen [:Matti]]

could be the checkin from bug 289491..

Comment 10

[Aaron Leventhal]

Attachment: Add null checks to prepare for case where document has no docshell

Comment 11

[Aaron Leventhal]

Comment on attachment 182454 [details] [diff] [review]
Add null checks to prepare for case where document has no docshell

Re-marking pkw's r+, I must have cleared it accidentally.

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 182454 [details] [diff] [review]
Add null checks to prepare for case where document has no docshell

a=asa

Comment 13

[Aaron Leventhal]

Checking in src/base/nsAccessNode.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessNode.cpp,v  <--  nsAccessNode.cpp
new revision: 1.25; previous revision: 1.24
done
Checking in src/base/nsAccessibilityService.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessibilityService.cpp,v  <-- 
nsAccessibilityService.cpp
new revision: 1.139; previous revision: 1.138
done

Comment 14

[William Price]

Ok... still crashes for me.  After Aaron's change, I get a different stack
trace.  The crash is now reported @ nsAccessibilityService::OnStateChange

TB5651916Y

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050505
Firefox/1.0+

Comment 15

[Benjamin Smedberg]

Please re-nominate or file a new bug if this new crash appears reproducibly on
trunk builds.

Comment 16

[Aaron Leventhal]

Is this still a bug? Does it occur in Firefox 1.5.0.4?

Comment 17

[William Price]

(In reply to comment #16)
> Is this still a bug? Does it occur in Firefox 1.5.0.4?

I've been working on Trunk builds and this particular issue has not come up for quite some time; I can't tell you about 1.5.x, though.  If it's of high importance, drop me mail and I can uninstall and load a branch build when I get home.

ASIDE: I have a current problem with builds on/after 20060622, but I've been lurking on bug 342607 and need to test with a recent nightly again to see if it's a problem.  It would seem that WinXP Tablet Edition is a great tool for finding accessibility-related issues.

Comment 18

[Aaron Leventhal]

Okay, the other thing was a separate problem.

Comment 19

[William Bumgarner [:zsinj]]

<- VERI based upon comment 18 from original reporter