955631 - [a11y] [regression] Mutation observers don't prevent firing two a11y focus events

Status: RESOLVED WONTFIX

(Instantbird Graveyard :: Contacts window, defect)

Description

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-09-27 19:02:00 UTC ***

Regression of bug 955056 (bio 1626) by bug 955182 (bio 1750).

Comment 1

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-09-27 19:03:05 UTC ***

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

Comment 2

[Instantbot]

*** Original post on bio 2186 by James Teh <jamie AT nvaccess.org> at 2013-10-23 23:19:56 UTC ***

Given that this is now hard/impossible to work around in Instantbird (I have no ideas), I've hacked around it in NVDA. Hopefully, the underlying Mozilla bug will get fixed eventually, at which point this hack can be removed.

Related NVDA ticket: http://community.nvda-project.org/ticket/2667

Comment 3

[Florian Quèze [:florian]]

*** Original post on bio 2186 at 2013-10-24 12:46:56 UTC ***

(In reply to comment #2)
> Given that this is now hard/impossible to work around in Instantbird (I have no
> ideas), I've hacked around it in NVDA.

Thanks!

Random idea: Have we tried adding a focus event listener, and calling .preventDefault() on the events that we know aren't wanted? Would that be enough to make the events not reach the accessibility tools?

Comment 4

[aleth [:aleth]]

Attachment: Patch

*** Original post on bio 2186 as attmnt 2980 at 2013-10-24 13:54:00 UTC ***

I have no idea if this will fix the problem, but it's worth a try and doesn't introduce any new hacks.

Comment 5

[Instantbot]

Comment on attachment 8354761 [details] [diff] [review]
Patch

*** Original change on bio 2186 attmnt 2980 by jamie AT nvaccess.org at 2013-10-25 08:50:05 UTC ***

Unfortunately, this doesn't make any difference. Thanks for trying, though. :)

Out of interest, Florian suggested calling .preventDefault() in the event handler, but I don't see this. Am I missing it or is it being done differently?

Comment 6

[Florian Quèze [:florian]]

*** Original post on bio 2186 at 2013-10-25 09:24:23 UTC ***

(In reply to comment #5)

> Out of interest, Florian suggested calling .preventDefault() in the event
> handler, but I don't see this. Am I missing it or is it being done differently?

I was also puzzled by this patch. It looks like it removes the old workaround that no longer works (worth doing anyway), but it doesn't seem to try anything new.

Comment 7

[Instantbot]

*** Original post on bio 2186 by James Teh <jamie AT nvaccess.org> at 2013-10-25 09:32:51 UTC ***

(In reply to comment #6)
> I was also puzzled by this patch. It looks like it removes the old workaround
> that no longer works (worth doing anyway), but it doesn't seem to try anything
> new.
Well, it does set a handler for the select event.

Comment 8

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-10-25 09:39:49 UTC ***

(In reply to comment #7)
> > I was also puzzled by this patch. It looks like it removes the old workaround
> > that no longer works (worth doing anyway), but it doesn't seem to try anything
> > new.
> Well, it does set a handler for the select event.

Exactly, the question was whether select for the listbox is handled early enough.

Comment 9

[aleth [:aleth]]

Attachment: Patch

*** Original post on bio 2186 as attmnt 2984 at 2013-10-25 09:41:00 UTC ***

Let's try the preventDefault idea then.

Comment 10

[aleth [:aleth]]

Comment on attachment 8354761 [details] [diff] [review]
Patch

*** Original change on bio 2186 attmnt 2980 at 2013-10-25 09:41:04 UTC was without comment, so any subsequent comment numbers will be shifted ***

Comment 11

[Instantbot]

Comment on attachment 8354765 [details] [diff] [review]
Patch

*** Original change on bio 2186 attmnt 2984 by jamie AT nvaccess.org at 2013-10-28 00:27:53 UTC ***

Unfortunately, no joy with this one either. :(

Comment 12

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-10-28 10:09:47 UTC ***

(In reply to comment #10)
> Unfortunately, no joy with this one either. :(

With hindsight, this is not surprising, as neither the unexpanded nor the expanded contact seem to ever receive a focus or a blur event, at least on Linux. Which is itself strange...

Comment 13

[Florian Quèze [:florian]]

*** Original post on bio 2186 at 2013-10-28 11:19:10 UTC ***

Isn't the focus on the richlistbox itself, so that the up/down arrow keys keep working?

Comment 14

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-10-28 15:52:38 UTC ***

(In reply to comment #12)
> Isn't the focus on the richlistbox itself, so that the up/down arrow keys keep
> working?

Since the listitem does receive keypress events (which generally get sent to the focused element), I assume this is not the case and the keypresses merely bubble to the listbox.

Comment 15

[Florian Quèze [:florian]]

*** Original post on bio 2186 at 2013-10-28 15:58:42 UTC ***

We forward the keypress event from the listbox, see http://lxr.instantbird.org/instantbird/source/instantbird/content/blist.js#829

Comment 16

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-10-28 16:18:13 UTC ***

(In reply to comment #14)
> We forward the keypress event from the listbox, see
> http://lxr.instantbird.org/instantbird/source/instantbird/content/blist.js#829

D'oh ;)

So as the focus always remains with the listbox, it seems the patch in comment 4 was the right thing to try here, and as it didn't work there appears to be nothing else we can listen for?

Comment 17

[aleth [:aleth]]

*** Original post on bio 2186 at 2013-11-16 19:20:16 UTC ***

When is the next version of NVDA scheduled to be released?

Do we know if other screenreaders will have similar problems with this mozilla bug?

Comment 18

[Florian Quèze [:florian]]

*** Original post on bio 2186 at 2013-11-22 07:11:00 UTC ***

No obvious next step here, so we can't block 1.5 on it.

Comment 19

[aleth [:aleth]]

Unassigning myself (I don't think this is fixable within IB code).

Comment 20

[Sylvestre Ledru [:Sylvestre]]

On the behalf of Florian:
Closing bugs related to the Instantbird UI as WONTFIX, as the development of the standalone chat client Instantbird has stopped. Instantbird users are encouraged to migrate to Thunderbird. The user interface of instant messaging in Thunderbird will feel familiar, as the Thunderbird IM support started as a fork of Instantbird.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

On the behalf of Florian:
Closing bugs related to the Instantbird UI as WONTFIX, as the development of the standalone chat client Instantbird has stopped. Instantbird users are encouraged to migrate to Thunderbird. The user interface of instant messaging in Thunderbird will feel familiar, as the Thunderbird IM support started as a fork of Instantbird.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

On the behalf of Florian:
Closing bugs related to the Instantbird UI as WONTFIX, as the development of the standalone chat client Instantbird has stopped. Instantbird users are encouraged to migrate to Thunderbird. The user interface of instant messaging in Thunderbird will feel familiar, as the Thunderbird IM support started as a fork of Instantbird.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

On the behalf of Florian:
Closing bugs related to the Instantbird UI as WONTFIX, as the development of the standalone chat client Instantbird has stopped. Instantbird users are encouraged to migrate to Thunderbird. The user interface of instant messaging in Thunderbird will feel familiar, as the Thunderbird IM support started as a fork of Instantbird.