963000 - Explore By Touch sometimes not working when Firefox is opened and automatically loads a web page

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Marco Zehe (:MarcoZ)]

I sometimes can reproduce this with these steps:
0. Make sure you have an older than the current version of Nightly installed, so that it can update itself.
1. With TalkBack on, open Nightly.
2. Open any web page.
3. Open the menu, Settings, Mozilla, About. This will open a new tab.
4. Find and double-tap "Check for uPdate", or "Install update" if it already is ready to install the new version.
5. Let it update itself.
6. At the end of the update process, tap Open to open this newly instaled instance of Nightly.

Result: It will open with the About page loaded in the current tab, and the other web page you had opened in step 2 in the other tab. The About page is in the foreground.

7. Try to explore the web content with your finger.

Expected: Should find web content.
Actual: Often, the web content cannot be found, and TalkBack emits plopping sounds to indicate it doesn't find anything to speak.

8. Open the Tabs pane. That part of the UI is accessible.
9. Hit the other tab.

Result: Functionality is now restored for explore by touch. At least most of the time. Sometimes, however, I have to close all tabs and start with a freshly opened page from the Home screen to actually get Explore By Touch working. This varies.

This happens on both Nexus 7 tablets of 2012 and 2013, and does not seem to be related to bug 961612, because this happened before that fix and still happens now.

Max, any ideas by chance?

Comment 1

[Max Li [:maxli]]

A quick look shows that AccessFu continues to receive and process the touch events, since the visual rectangle we draw continues to be drawn as expected. Looking at the TalkBack logs, it doesn't seem to get to the point where it's processing the TYPE_VIEW_ACCESSIBILITY_FOCUSED events, which is why it's silent. Not sure why that is.

Comment 2

[Max Li [:maxli]]

An easier way to replicate this is to close Firefox with the session restore setting turned on, and then open it up again, which seems to replicate this bug reliably.

In doing that, it seems like TalkBack skips focusing the nodes because it thinks they aren't visible in this situation.

Comment 3

[Max Li [:maxli]]

Attachment: Patch

The reason that the node is not considered to be visible is because in bug 906670, I changed it so that nodes are only considered to be visible if the view is focused, which is apparently not true in this case. Instead, it probably makes more sense just to check for the view's visibility.

Marco, could you try this patch and see if there's any strange behavior (in particular with respect to the behaviour upon initial load (both directly into a webpage and not), changing tabs, and the issues in bug 906670)?

Comment 4

[Marco Zehe (:MarcoZ)]

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

This works as expected. I can now access the content right after a page loads and also with the steps you describe. Also, it does not regress bug 906670. When bringing up the Awesome Screen from within a web page, I can neither touch, nor swipe to web content lying underneath. Good work!

Comment 5

[Marco Zehe (:MarcoZ)]

Moving this to correct product/component, since it is not an AccessFu bug, but one in the native widget layer accessibility.

Comment 6

[Marco Zehe (:MarcoZ)]

This bug was introduced in bug 906670, landed on Firefox for Android 26. Requesting tracking and setting Affected flags from 27 to 29 since we may want to relnote for 27, but uplift to 28 (and 29 if it lands on 30 after today's merge). There is a workaround for those affected by it in 26 and 27: Open a new web page or switch to a different tab. But we should definitely get this fixed for versions back to 28.

Comment 7

[Aaron Train [:aaronmt]]

Re comment #6

Comment 8

[Max Li [:maxli]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/54001ad1dfb7

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/54001ad1dfb7

Comment 10

[bhavana bajaj [:bajaj]]

(In reply to Aaron Train [:aaronmt] from comment #7)
> Re comment #6


Given this was already Firefox26 affected and we never noted it as a known issue I am not sure if we really want to for Fx27(may seem like a new issue in Fx27 if we did) unless you have seen any dup reports/playstore feed back etc or other noise as we tend not to overload the release notes unless its a critical user issue.

Also looks like there is a existing workaround per comment #6. I'd just get this uplifted to Fx28 though.

Comment 11

[Marco Zehe (:MarcoZ)]

Verified fixed in 30.0a1 (2013-02-04).

Comment 12

[Marco Zehe (:MarcoZ)]

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

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 906670
User impact if declined: Blind users will not be able to explore content when a page initially loads after starting Firefox.
Testing completed (on m-c, etc.): Yes.
Risk to taking this patch (and alternatives if risky): None.
String or IDL/UUID changes made by this patch: None.

Comment 13

[Marco Zehe (:MarcoZ)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e9f5361461a8
https://hg.mozilla.org/releases/mozilla-beta/rev/e2a1bea4fc8b

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/e2a1bea4fc8b