362532 - accessibility: crashes while arrowing down treetable in account settings

Status: RESOLVED WORKSFORME

(Thunderbird :: Account Manager, defect)

Description

[Lynn Monsanto]

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:  
crash

Expected Results:  
should not crash

Comment 1

[Magnus Melin [:mkmelin]]

Please include the talkback id for the crash when reporting crashes. (http://kb.mozillazine.org/Talkback)

Comment 2

[Evan Yan]

confirmed.

Comment 3

[Evan Yan]

Attachment: core stack

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: 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

[David :Bienvenu]

I think a little (or a lot :-) ) more of the stack would be useful.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: backtrace

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.

Comment 7

[David :Bienvenu]

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

[Aaron Leventhal]

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.

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

Can anyone confirm (or has anyone confirmed) this bug on other platforms?

Comment 10

[Evan Yan]

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.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

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.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

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

[Lynn Monsanto]

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

However, https://bugzilla.mozilla.org/show_bug.cgi?id=364275 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.

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

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.

Comment 15

[Magnus Melin [:mkmelin]]

->WFM (FIXED is only used when known code changes resolved the issue)

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

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

[Magnus Melin [:mkmelin]]

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.

Comment 18

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381