757418 - [AccessFu] On some Wikipedia pages, document title is repeated whenever returning from a link

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. Open http://en.wikipedia.org/wiki/Kylie_Minogue in Firefox Android with AccessFu enabled.
2. Start navigating the article.

Notice that, whenever on a link and navigating to the next element, Talkback will repeat the document title again before reading the actual next chunk of text.

I also notice, with SoundBack enabled, that in these instances, often two clicks are heard, even though only one element is being moved forward.

Comment 1

[Eitan Isaacson [:eeejay]]

Yeah, that is an unfortunate regression.

Comment 2

[Eitan Isaacson [:eeejay]]

Attachment: Do Presenter.tabSelected when tab's window receives focus.

Don't use the document focus event since it will happen now every time we blur a focasable child. Instead use the DOM focus event for the window of the tab.

Comment 3

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

Comment on attachment 626093 [details] [diff] [review]
Do Presenter.tabSelected when tab's window receives focus.

Review of attachment 626093 [details] [diff] [review]:
-----------------------------------------------------------------

r=me.

::: accessible/src/jsat/AccessFu.jsm
@@ +73,5 @@
>      this.chromeWin.addEventListener('DOMActivate', this, true);
>      this.chromeWin.addEventListener('resize', this, true);
>      this.chromeWin.addEventListener('scroll', this, true);
>      this.chromeWin.addEventListener('TabOpen', this, true);
> +    this.chromeWin.addEventListener('focus', this, true);

OK AIUI this will only happen when the tab changes (not as chatty as our a11y focus event for the document... which maybe we should fix in core).

@@ -309,5 @@
>            break;
>          }
> -      case Ci.nsIAccessibleEvent.EVENT_FOCUS:
> -        {
> -          if (this._isBrowserDoc(aEvent.accessible)) {

Only one consumer of _isBrowserDoc left but OK.

Comment 4

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

Eitan assures me the a11y engine focus events are correct.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to David Bolter [:davidb] from comment #4)
> Eitan assures me the a11y engine focus events are correct.

I'm not sure how it goes with comment #2 "Don't use the document focus event since it will happen now every time we blur a focasable child." Does it happen for example if you tab by links?

The problem of DOM focus (and why we fire focus event on blur) is when focus goes to document (for example shift+tab from focusable element) then there's no DOM focus event (since DOM document stays focused). We coalesce focus events and thus usually we don't get two focus events but if this doesn't happen then somebody should debug that (i.e. why blur and focus events have timeout).

Also since you are switching to DOM focus then you don't get notifications for selects (comboboxes, listboxes), trees, menus navigation. Also you don't get proper notifications for ARIA activedescendant changes. If you need that then you regress probably worst than you win.

Comment 6

[Marco Zehe (:MarcoZ)]

FWIW, NVDA also focused focusable items when navigating by virtual cursor. If the next item the v cursor lands on is not focusable, the last focused item remains focused until something new focusable is reached. They never set focus back to the document in the interim.

Comment 7

[Marco Zehe (:MarcoZ)]

Also FWIW, there is no tabbing between links yet in Android.

Comment 8

[alexander :surkov (:asurkov)]

(In reply to Marco Zehe (:MarcoZ) from comment #6)
> FWIW, NVDA also focused focusable items when navigating by virtual cursor.
> If the next item the v cursor lands on is not focusable, the last focused
> item remains focused until something new focusable is reached. They never
> set focus back to the document in the interim.

Thanks, Marco. I see now what happens. It sounds as a way to go.

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8344de0f1079

Comment 10

[Eitan Isaacson [:eeejay]]

(In reply to alexander :surkov from comment #5)
> (In reply to David Bolter [:davidb] from comment #4)
> > Eitan assures me the a11y engine focus events are correct.
> 
> I'm not sure how it goes with comment #2 "Don't use the document focus event
> since it will happen now every time we blur a focasable child." Does it
> happen for example if you tab by links?
> 

What we are doing is more similar to caret navigation. If you press right arrow through a link to regular text, the focus leaves the link and does back to the document.

> Also since you are switching to DOM focus then you don't get notifications
> for selects (comboboxes, listboxes), trees, menus navigation. Also you don't
> get proper notifications for ARIA activedescendant changes. If you need that
> then you regress probably worst than you win.

The only use for the focus event, at least now, is for document tab changes.

Comment 11

[Eitan Isaacson [:eeejay]]

(In reply to Marco Zehe (:MarcoZ) from comment #6)
> FWIW, NVDA also focused focusable items when navigating by virtual cursor.
> If the next item the v cursor lands on is not focusable, the last focused
> item remains focused until something new focusable is reached. They never
> set focus back to the document in the interim.

We don't only set focus back to the document, we keep the caret at the vc position. So if you press tab (maybe on a bluetooth keyboard?) when the vc is in a non-focusable text, the focusable element after it will get focus, and not the first item on the doc.

To me this seems like a good way to harmonize virtual cursor and tab focus order.

Comment 12

[Marco Zehe (:MarcoZ)]

Verified fixed in Fennec/15.0a1 2012-05-24 Android.