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

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
14 years ago
13 years ago

People

(Reporter: bugzilla-mozilla, Assigned: aaronlev)

Tracking

(4 keywords)

Trunk
x86
Windows XP
crash, hang, regression, topcrash+
Points:
---
Bug Flags:
blocking1.8b3 -
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
keywords -> regression, crash, hang
Keywords: crash, hang, regression
Version: unspecified → Trunk
Do you see this if you run firefox in the safemode ?
(just to be sure that this is not injected by an extension)
Assignee: firefox → aaronleventhal
Component: General → Disability Access
QA Contact: general → bugzilla
Summary: [regression] Crashes or hangs randomly when opening new links, closing tabs, opening new links in tabs → [regression] Crashes or hangs randomly when opening new links, closing tabs, opening new links in tabs [@ nsAccessNode::GetDocShellTreeItemFor]
(Reporter)

Comment 3

14 years ago
(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.
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
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.
(Reporter)

Comment 6

14 years ago
(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?
(Reporter)

Comment 7

14 years ago
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

14 years ago
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: topcrash+
could be the checkin from bug 289491..
(Assignee)

Comment 10

14 years ago
Created attachment 182454 [details] [diff] [review]
Add null checks to prepare for case where document has no docshell
(Assignee)

Updated

14 years ago
Attachment #182454 - Flags: superreview?(bzbarsky)
Attachment #182454 - Flags: review?(pkwarren)
Attachment #182454 - Flags: superreview?(bzbarsky) → superreview+

Updated

14 years ago
Attachment #182454 - Flags: review?(pkwarren) → review+
(Assignee)

Updated

14 years ago
Component: Disability Access → Disability Access APIs
Flags: review+
Product: Firefox → Core
(Assignee)

Comment 11

14 years ago
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.
Attachment #182454 - Flags: review+
(Assignee)

Updated

14 years ago
Attachment #182454 - Flags: approval1.8b2?

Comment 12

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

a=asa
Attachment #182454 - Flags: approval1.8b2? → approval1.8b2+
(Assignee)

Comment 13

14 years ago
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
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

14 years ago
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+
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [regression] Crashes or hangs randomly when opening new links, closing tabs, opening new links in tabs [@ nsAccessNode::GetDocShellTreeItemFor] → [regression] Crashes or hangs randomly when opening new links, closing tabs, opening new links in tabs [@ nsAccessNode::GetDocShellTreeItemFor] [@ nsAccessibilityService::OnStateChange]

Updated

14 years ago
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?

Comment 15

14 years ago
Please re-nominate or file a new bug if this new crash appears reproducibly on
trunk builds.
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
(Assignee)

Comment 16

13 years ago
Is this still a bug? Does it occur in Firefox 1.5.0.4?
(Reporter)

Comment 17

13 years ago
(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.
(Assignee)

Comment 18

13 years ago
Okay, the other thing was a separate problem.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED
<- VERI based upon comment 18 from original reporter
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsAccessNode::GetDocShellTreeItemFor] [@ nsAccessibilityService::OnStateChange]
You need to log in before you can comment on or make changes to this bug.