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

VERIFIED FIXED in Firefox 28

Status

()

defect
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: MarcoZ, Assigned: maxli)

Tracking

({access, regression})

Trunk
Firefox 30
All
Android
Points:
---

Firefox Tracking Flags

(firefox27- wontfix, firefox28+ fixed, firefox29+ fixed, firefox30 verified, b2g-v1.3 fixed, b2g-v1.4 fixed, relnote-firefox 28+)

Details

Attachments

(1 attachment)

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?
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.
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.
Posted patch PatchSplinter Review
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)?
Assignee: nobody → maxli
Attachment #8369153 - Flags: feedback?(marco.zehe)
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!
Attachment #8369153 - Flags: feedback?(marco.zehe) → feedback+
Component: Disability Access APIs → General
Product: Core → Firefox for Android
Summary: [AccessFu] Explore By Touch sometimes not working when Firefox is opened and automatically loads a web page → Explore By Touch sometimes not working when Firefox is opened and automatically loads a web page
Moving this to correct product/component, since it is not an AccessFu bug, but one in the native widget layer accessibility.
Keywords: access, regression
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.
Attachment #8369153 - Flags: review?(bugmail.mozilla)
Re comment #6
Flags: needinfo?(bbajaj)
https://hg.mozilla.org/mozilla-central/rev/54001ad1dfb7
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
(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.
Flags: needinfo?(bbajaj)
Verified fixed in 30.0a1 (2013-02-04).
Status: RESOLVED → VERIFIED
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.
Attachment #8369153 - Flags: approval-mozilla-beta?
Attachment #8369153 - Flags: approval-mozilla-aurora?
Attachment #8369153 - Flags: approval-mozilla-beta?
Attachment #8369153 - Flags: approval-mozilla-beta+
Attachment #8369153 - Flags: approval-mozilla-aurora?
Attachment #8369153 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.