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.
Have this ability would be extremely helpful, I hope it will be reviewed and included in an upcoming beta edition!
I seriously might consider changing to Chrome over this. I want RescueTime on Android, and I want a consistent experience everywhere.
I want to test this, and see what can be done. needinfoing myself so this happens.
Created attachment 8547724 [details] [diff] [review] Dispatch a11y selection changed events on the address bar even when the text edit is hidden.
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.
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
(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!