Last Comment Bug 757418 - [AccessFu] On some Wikipedia pages, document title is repeated whenever returning from a link
: [AccessFu] On some Wikipedia pages, document title is repeated whenever retur...
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: ARM Android
: -- major (vote)
: mozilla15
Assigned To: Eitan Isaacson [:eeejay]
:
Mentors:
http://en.wikipedia.org/wiki/Kylie_Mi...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-22 06:13 PDT by Marco Zehe (:MarcoZ)
Modified: 2012-05-24 09:09 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Do Presenter.tabSelected when tab's window receives focus. (4.19 KB, patch)
2012-05-22 11:04 PDT, Eitan Isaacson [:eeejay]
dbolter: review+
Details | Diff | Splinter Review

Description Marco Zehe (:MarcoZ) 2012-05-22 06:13:48 PDT
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] 2012-05-22 09:09:28 PDT
Yeah, that is an unfortunate regression.
Comment 2 Eitan Isaacson [:eeejay] 2012-05-22 11:04:45 PDT
Created attachment 626093 [details] [diff] [review]
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] 2012-05-22 12:38:33 PDT
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] 2012-05-22 12:40:55 PDT
Eitan assures me the a11y engine focus events are correct.
Comment 5 alexander :surkov 2012-05-22 20:54:35 PDT
(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) 2012-05-22 21:24:38 PDT
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) 2012-05-22 21:25:01 PDT
Also FWIW, there is no tabbing between links yet in Android.
Comment 8 alexander :surkov 2012-05-22 22:17:24 PDT
(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] 2012-05-23 05:06:15 PDT
https://hg.mozilla.org/mozilla-central/rev/8344de0f1079
Comment 10 Eitan Isaacson [:eeejay] 2012-05-23 09:39:53 PDT
(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] 2012-05-23 09:43:05 PDT
(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) 2012-05-24 09:09:06 PDT
Verified fixed in Fennec/15.0a1 2012-05-24 Android.

Note You need to log in before you can comment on or make changes to this bug.