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

RESOLVED FIXED in Firefox 38



6 years ago
3 years ago


(Reporter: mark, Assigned: eeejay)



23 Branch
Firefox 38

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
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

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

Comment 2

4 years ago
I seriously might consider changing to Chrome over this. I want RescueTime on Android, and I want a consistent experience everywhere.
Ever confirmed: true
Keywords: access
OS: Mac OS X → Android
Hardware: x86 → ARM

Comment 3

4 years ago
I want to test this, and see what can be done. needinfoing myself so this happens.
Flags: needinfo?(eitan)


4 years ago
Flags: needinfo?(eitan)
Attachment #8547724 - Flags: review?(mark.finkle)
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.
Attachment #8547724 - Flags: review?(mark.finkle) → review+

Comment 6

4 years ago
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.


Comment 7

4 years ago
(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.

Any testing is appreciated!


4 years ago
Assignee: nobody → eitan
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
You need to log in before you can comment on or make changes to this bug.