accessibility: crashes while arrowing down treetable in account settings



Account Manager
12 years ago
12 years ago


(Reporter: Lynn Monsanto, Assigned: davidb)


({access, sec508})

access, sec508

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
Build Identifier: version 3 alpha 1 (20061201)

With Ubuntu assistive technologies enabled, Thunderbird crashes arrowing down left-hand treetable in account settings dialog. Note this crash does not occur when assistive technologies are not enabled.

Reproducible: Always

Steps to Reproduce:
1. Enable assistive technologies
2. Launch Thunderbird 3
3. Open account preferences and arrow down the treetable on the left-hand side of the dialog.  Thunderbird will crash.

Actual Results:  

Expected Results:  
should not crash


12 years ago
Keywords: access, sec508

Comment 1

12 years ago
Please include the talkback id for the crash when reporting crashes. (

Comment 2

12 years ago
Ever confirmed: true
Version: unspecified → Trunk

Comment 3

12 years ago
Created attachment 247522 [details]
core stack
Created attachment 247723 [details]
gdb where output

Confirming bug on my system (Ubuntu Edgy Eft). Here is a teaser of the last few commands in the stack:
(gdb) where
#0  0x00000049 in ?? ()
#1  0xb5a3d612 in nsAccessible::QueryInterface (this=0x8bb2128, aIID=@0xb5aac11c, aInstancePtr=0xbfbfe55c)
    at /home/dtb/mozworkspace/mozilla/accessible/src/base/nsAccessible.cpp:152
#2  0xb7cabfa2 in nsQueryInterface::operator() (this=0xbfbfe570, aIID=@0xb5aac11c, answer=0xbfbfe55c) at nsCOMPtr.cpp:47

Comment 5

12 years ago
I think a little (or a lot :-) ) more of the stack would be useful.
Created attachment 247725 [details]

OK :-)
Here is a bit more backtrace. I'm a bit rusty with gdb but please let me know if this helps or if you need more specific stack frame info etc.
Attachment #247723 - Attachment is obsolete: true

Comment 7

12 years ago
that's a lot more interesting - it's probably even useful for someone who understands the code, like Aaron :-) This looks like a core accessibility bug, if I'm understanding correctly.

Comment 8

12 years ago
David Bolter is our guy for Tbird a11y now. He's new to Mozilla but not a11y, so everyone help him out on Mozilla stuff if possible.
Assignee: mscott → david.bolter
Can anyone confirm (or has anyone confirmed) this bug on other platforms?

Comment 10

12 years ago
similar backtrace with bug 340480, and this bug has more stable reproduce steps.

marking as dependency instead of dupe, until we know this bug really fixes that one.
Blocks: 340480
For this case the following sequence seems to happen (picking out bits of the stack trace): 
1. we arrow down, 
2. nsDocumentOnPageHide  triggers, 
3. nsDocAccessible::Destroy is called, and 
4. during cache cleanup we try to QueryInterface using a defunct object (pointer)

I'd like to chat with people about the cache.
I tried recreating this bug with my first build after the holidays (pulled from HEAD today).  I can not recreate it.

Can someone else confirm that this bug is perhaps fixed/obsolete?

Comment 13

12 years ago
I cannot reproduce this bug on version 3 alpha 1 (20070108).  

However, is still a major problem that makes the Account Settings dialog (and other dialogs) very confusing for people with disabilities. For example, in the Security page, the following text does not have LABEL_FOR assigned:

1. "To send and receive signed..."
2. "Use this certificate to digitally..."
3. "Use this certificate to encrypt..."
4. "Default encryption settings when..."

This means that assistive technologies cannot speak/Braille the appropriate text for the component that has focus.

For example, an assisive technology should only speak "Use this certificate to encrypt..." when the Encryption text field has keyboard focus.
Lynn.  Thanks for confirming.

OK, I'm closing this as fixed (seemed the closest option). Please reopen if/as necessary. I wish I knew what the "fix" was though.

I'll take a look at bug 364275.
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 15

12 years ago
->WFM (FIXED is only used when known code changes resolved the issue)
Thanks Magnus. I was going to close WFM but since the specific guilty build version was specified in the report I felt that didn't quite fit.  I'll follow your convention in the future though. Sorry about that.

Comment 17

12 years ago
No problem. It's more for tracking purpose I suppose, and in cases someone want to find out how to fix a related bug, they may get inspiration by searching related fixed bugs and look at the patches.
You need to log in before you can comment on or make changes to this bug.