Last Comment Bug 908224 - Does not propagate page navigation changes to awesome bar with accessibility event
: Does not propagate page navigation changes to awesome bar with accessibility ...
Status: RESOLVED FIXED
: access
Product: Firefox for Android
Classification: Client Software
Component: General (show other bugs)
: 23 Branch
: ARM Android
: -- normal with 3 votes (vote)
: Firefox 38
Assigned To: Eitan Isaacson [:eeejay]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-22 08:49 PDT by Mark Wolgemuth
Modified: 2015-01-12 19:42 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Dispatch a11y selection changed events on the address bar even when the text edit is hidden. (3.26 KB, patch)
2015-01-12 11:32 PST, Eitan Isaacson [:eeejay]
mark.finkle: review+
Details | Diff | Review

Description Mark Wolgemuth 2013-08-22 08:49:31 PDT
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 2013-08-27 16:22:11 PDT
Have this ability would be extremely helpful, I hope it will be reviewed and included in an upcoming beta edition!
Comment 2 Tom Palmer 2014-12-11 13:57:18 PST
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] 2015-01-05 12:36:55 PST
I want to test this, and see what can be done. needinfoing myself so this happens.
Comment 4 Eitan Isaacson [:eeejay] 2015-01-12 11:32:31 PST
Created attachment 8547724 [details] [diff] [review]
Dispatch a11y selection changed events on the address bar even when the text edit is hidden.
Comment 5 Mark Finkle (:mfinkle) (use needinfo?) 2015-01-12 11:52:10 PST
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 2015-01-12 12:16:52 PST
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] 2015-01-12 12:57:05 PST
(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 9 Wes Kocher (:KWierso) 2015-01-12 19:42:18 PST
https://hg.mozilla.org/mozilla-central/rev/110c7c32c1fb

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