908224 - Does not propagate page navigation changes to awesome bar with accessibility event

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Mark Wolgemuth]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/536.30.1 (KHTML, like Gecko) Version/6.0.5 Safari/536.30.1

Steps to reproduce:

Enable Accessibility to support our app (RescueTime), and capture events that cause URL change. Observe events that indicate changes to AwesomeBar location status.


Actual results:

If a user is actually entering or selecting for suggestions something in AwesomeBar, then a AccessibilityEvent.TYPE_VIEW_TEXT_SELECTION_CHANGED or AccessibilityEvent.TYPE_VIEW_CLICKED event is fired for that UI element, depending.  This behavior is similar to Chrome for Android and Android native browser.

However, if a user taps or otherwise navigates to a new location via page content itself, no event is fired to indicate that what is current in the AwesomeBar has changed. There is a AccessibilityEvent.TYPE_WINDOW_CONTENT_CHANGED event that does get fired (which is expected, just making an observation).


Expected results:

If a user navigates to a location resulting in a change of URL, Firefox for Android should do one of our both:

1) Fire a AccessibilityEvent.TYPE_VIEW_TEXT_SELECTION_CHANGED for the AwesomeBar element (this would mimic what the other android browsers do)

and/or (preferrably and)

2) Include a current URL in the metadata for AccessibilityEvent.TYPE_WINDOW_CONTENT_CHANGED event that is fired for the content window. Right now only the html title is noted, and in certain circumstances the domain is prepended to the title. 

This information would allow accessibility services to perform specific desired behaviors when the user navigates out of current site or page.

RescueTime itself depends on this for our users reporting needs, and has been requested a number of times.

Comment 1

[Nathan Sudds]

Have this ability would be extremely helpful, I hope it will be reviewed and included in an upcoming beta edition!

Comment 2

[Tom Palmer]

I seriously might consider changing to Chrome over this. I want RescueTime on Android, and I want a consistent experience everywhere.

Comment 3

[Eitan Isaacson [:eeejay]]

I want to test this, and see what can be done. needinfoing myself so this happens.

Comment 4

[Eitan Isaacson [:eeejay]]

Attachment: Dispatch a11y selection changed events on the address bar even when the text edit is hidden.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8547724 [details] [diff] [review]
Dispatch a11y selection changed events on the address bar even when the text edit is hidden.

LGTM. Let's keep an eye open for possible regressions.

Comment 6

[Mark Wolgemuth]

Great news guys. 

If you have a beta build on the play store or some other way you want me to test, let me know.

Thanks,
Mark

Comment 7

[Eitan Isaacson [:eeejay]]

(In reply to Mark Wolgemuth from comment #6)
> Great news guys. 
> 
> If you have a beta build on the play store or some other way you want me to
> test, let me know.

This will hopefully be fixed in a nightly build later this week.
https://nightly.mozilla.org/

Any testing is appreciated!

Comment 8

[Eitan Isaacson [:eeejay]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/110c7c32c1fb

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/110c7c32c1fb