886077 - Can't access address bar using Spiel screen reader

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Max Li [:maxli]]

Exploring by touch or flicking left/right does not seem to be able to find it.

Seems to be a regression that was introduced in Firefox 23.

Comment 1

[Marco Zehe (:MarcoZ)]

Here's some more information gathered from the e-mail that was sent to me regarding this issue:

"Before I will try to describe my findings I must say I have tried Firefox beta which is currently at version 22.0 and with this version everything is working as it should and the title saying "Enter search or address" at the top of the main Firefox window is accessible while using that version.

At the right hand side on the top of the main Firefox window there is a view of type android.widget.RelativeLayout. Inside this view there is a button which is used to open a list of currently open tabs.
This android.widget.RelativeLayout has its ContentDescription set to the name of the currently loaded website or there is a text "enter search or address" when no page is currently loaded.
I am afraid this was not always like that and mostlikelly there was a text view or another control inside the android.widget.RelativeLayout I am talking about all the time.

I am afraid this was not an accessibility related change, perhaps this was a visually oriented change but according to the spiel author's response to my quest for a fix to this situation it would require a serious rewrite of spiel functionality in order to be able to change its presentation paradigm to be able to make this android.widget.RelativeLayout anounced via speech.
Additionally it is not possible to distinguish this instance of android.widget.RelativeLayout from other views of this type therefore it is also inpossible to try to come up with a script in order to try to come up with a solution via scripting."

So, some overloading of relativeLayout caused this breakage. I wasn't even aware you could assign contentDescription to this purely layout-providing element! We should try to get this fixed properly.

Comment 2

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

Is this a problem in any other screen readers?

Comment 3

[Marco Zehe (:MarcoZ)]

It is a problem in Spiel, a widely used screen reader for Android. It is not a problem in TalkBack, the screen reader that comes bundled with Android. However, Spiel is particularly favored among real power users. Its spacial representation of elements is more accurate than TalkBack's, and it is scriptable, which means it can be easily enhanced without having to actually build the whole project.

While TalkBack accounts for such things as a contentDescription on a android:relativeLayout element, and it simply puts it whereever it thinks it fits in the spacial representation, Spiel's architecture is different, and layout elements are strictly treated as such.

Comment 4

[Max Li [:maxli]]

Attachment: Patch

Lucas, you added these lines which seem to be causing the problem. What problem was that trying to solve? AFAICT everything still works fine after removing these, but I don't know if I missed something.

Marco, could you check (in both TalkBack and Spiel) to make sure I haven't missed breaking anything obvious?

Comment 5

[Marco Zehe (:MarcoZ)]

Max, what bug does that change point to? I seem to remember we did have to do something like this a year ago to solve the duplication of a button in the awesome bar, I believe having to do with the site security or so. I am building with this patch now to see if that problem then occurs again. Anyway, looking in the original bug might provide some more context.

Comment 6

[Max Li [:maxli]]

(In reply to Marco Zehe (:MarcoZ) from comment #5)
> Max, what bug does that change point to? I seem to remember we did have to
> do something like this a year ago to solve the duplication of a button in
> the awesome bar, I believe having to do with the site security or so. I am
> building with this patch now to see if that problem then occurs again.
> Anyway, looking in the original bug might provide some more context.

The changeset is the last of bug 858687. I don't see any mentions of anything accessibility related at all in that bug.

Comment 7

[Max Li [:maxli]]

(In reply to Max Li [:maxli] from comment #6)
> The changeset is the last of bug 858687. I don't see any mentions of
> anything accessibility related at all in that bug.

After a little more investigation, that line was introduced in bug 771380 in which you do see that duplication. But the bug above appears to be where the regression happened.

Comment 8

[Marco Zehe (:MarcoZ)]

Comment on attachment 767121 [details] [diff] [review]
Patch

I can confirm that this fixes the missing control in Spiel, and that it does not seem to reintroduce bug 771380. The conditions described in bug 771380 comment #44 no longer seem to apply due to several rewrites of that component. f=me.

Comment 9

[Aaron Train [:aaronmt]]

Firefox-22 is not affected, right?

Comment 10

[Max Li [:maxli]]

(In reply to Aaron Train [:aaronmt] from comment #9)
> Firefox-22 is not affected, right?

Correct.

Comment 11

[Max Li [:maxli]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/74357fe0651d

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/74357fe0651d

Comment 13

[Marco Zehe (:MarcoZ)]

Verified fixed in Firefox 25.0a1 (2013-06-27) by both me and Peter, who originally reported the bug to us.

Comment 14

[Marco Zehe (:MarcoZ)]

Comment on attachment 767121 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 858687
User impact if declined: Blind users of the alternative Android screen reader Spiel could no longer access the button to enter an address or search term in the awesome bar.
Testing completed (on m-c, etc.): Yes.
Risk to taking this patch (and alternatives if risky): None known.
String or IDL/UUID changes made by this patch: None.

Comment 15

[Marco Zehe (:MarcoZ)]

This got broken again between the 2013-06-28 and 2013-06-29 builds. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8e3a124c9c1a&tochange=c5ce065936fa

Max, can you investigate what happened? It looks like the patch was reverted.

Comment 16

[Max Li [:maxli]]

(In reply to Marco Zehe (:MarcoZ) from comment #15)
> This got broken again between the 2013-06-28 and 2013-06-29 builds. The
> regression range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=8e3a124c9c1a&tochange=c5ce065936fa
> 
> Max, can you investigate what happened? It looks like the patch was reverted.

Seems like the patch for bug 887020 (written around the same time as my patch) reverted it.

Comment 17

[Marco Zehe (:MarcoZ)]

Can you re-land on inbound? Or does the patch have to be rewritten?

Comment 18

[Max Li [:maxli]]

Relanded on inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/d3a746cf592d

Comment 19

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/d3a746cf592d

Comment 20

[Marco Zehe (:MarcoZ)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/eacfed5e3e6d
https://hg.mozilla.org/releases/mozilla-beta/rev/8f46772eb561

Comment 21

[Marco Zehe (:MarcoZ)]

Re-landed bug fix verified in the Firefox 25.0a1 nightly build of 2013-07-01.

Comment 22

[Marco Zehe (:MarcoZ)]

Verified fixed in Firefox Aurora 24.0a2 (2013-07-02).

Comment 23

[Marco Zehe (:MarcoZ)]

Verified fixed in Firefox 23 Beta (2013-07-02)