Closed Bug 1191687 Opened 9 years ago Closed 9 years ago

Opening some links with VoiceOver shows context menu ("Open in New Tab" etc.)

Categories

(Firefox for iOS :: Browser, defect)

All
iOS 8
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
fxios-v1.0.5 --- fixed
fxios-v1.1 --- fixed
fxios 1.0.5+ ---

People

(Reporter: dusek, Assigned: bnicholson)

References

(Blocks 1 open bug)

Details

(Keywords: access, regression)

Attachments

(1 file, 1 obsolete file)

When I confirm some links on the web, then in addition to the browser starting navigation to the new page, a context menu (sheet) is also displayed that is normally displayed only after long-pressing the link. This quite seriously degrades the core browsing experience for VoiceOver users.

The issue does not happen on every link, but happens often enough to be significant.

Steps to reproduce:
1. Open www.google.com
2. Enter "Alamofire" into the search field and confirm on keyboard using the "Search" button
3. When the results page loads, turn on VoiceOver
4. Navigate the VoiceOver cursor to the "Alamofire/Alamofire - GitHub" link (by directly touching it, or flicking right with one finger)
5. Open the link (by double-tapping anywhere on the screen, or by split-tap - hold the link with one finger and tap once anywhere on the screen with another finger)

Expected Results:
The Alamofire's GitHub page would start loading, and eventually load.

Actual Results:
The Alamofire's GitHub page starts loading and at the same time an action sheet with "Open In New Tab" and "Copy Link" with title "https://github.com/Alamofire/Alamofire" is displayed. Notwithstanding this, the webpage loading continues in spite of the action sheet being displayed. What is even more strange (what I consider a VoiceOver bug), after the webpage fully loads, sometimes the VoiceOver cursor moves into the webpage, even though the modal sheet is still being displayed. But sometimes, it stays in the sheet (this I would guess is probably based on relative timing of some events due to different pages loading differently long - it seems for swiftly loading pages, the sheet is displayed after the page is loaded, and the VO cursor stays in it, but for pages that take long to load, i.e. that load after the sheet is displayed, the VO cursor moves to the sheet first when that is shown, and then to the webpage when that is loaded).

The user can dismiss the sheet (when in it) using the scrub "escape" gesture.

The sheet is sometimes triggered even by an accessibility scrub "escape" gesture.

This is a regression, as this issue used to not be present (but I cannot really say since when).
Brian, as you implemented the context menu, do you please have any first idea what could be going on, and hopefully also how to fix it?
Flags: needinfo?(bnicholson)
Thanks for pointing this out -- I'll take a look today.
Assignee: nobody → bnicholson
Status: NEW → ASSIGNED
Hmm, I can't seem to reproduce this. Not sure if it matters, but are you using Yahoo as your search engine? About how often does this happen?
Flags: needinfo?(dusek)
Oops, overlooked step 1 :)
Flags: needinfo?(dusek)
(In reply to Brian Nicholson (:bnicholson) from comment #4)
> Oops, overlooked step 1 :)

That is a relief :-)
Flags: needinfo?(bnicholson)
Attachment #8647187 - Flags: review?(sleroux)
Attachment #8647187 - Flags: review?(sarentz)
Attachment #8647187 - Flags: review?(rnewman)
Comment on attachment 8647187 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/918

LGTM
Attachment #8647187 - Flags: review?(sarentz) → review+
Attachment #8647187 - Flags: review?(sleroux)
Attachment #8647187 - Flags: review?(rnewman)
https://github.com/mozilla/firefox-ios/commit/43ccdf0a3257b171c8573b00608b2f3fe4a2fb4f
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
TL;DR:
can still repro it with the "Learn about Mozilla Advocacy" link at https://www.mozilla.org/en-US

Detailed version:
The issue is no longer reproducible with the page I submitted. But it is reproducible with another page:

On https://www.mozilla.org/en-US, with VoiceOver on, flick with one finger right until you reach the "Learn about Mozilla Advocacy" link (I counted you need to flick 5 times). Then quickly double-tap anywhere on the screen to open the link - the action sheet gets shown while the page is being loaded (i.e. I get the "Actual Results", not the "Expected Results").

(practical note for doing repro: When flicking right with one finger, don't let yourself distract with the weird scrolling behavior and VoiceOver cursor not being entirely on the right place on webpage - just keep going until "Lear about Mozilla Advocacy" link gets visible and VoiceOver says its name (when the link is visible, you can also simply touch it to focus VO cursor on it before doing the double-tap). Also, scrolling to the link before turning VoiceOver on to save you doing the flicking with one finger won't work - as soon as VoiceOver is turned on, VoiceOver scrolls to the top of the webpage. So you have )

If you have trouble with reproducing including working with VoiceOver, please let me know.

Tested on latest master: 7e2a58a0eda9afc6bc87afe0b83a32fbfa75cef2
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It looks like we aren't getting mouseup events in this case. I think the bug is that touchstart is fired at all for VoiceOver, which is particularly annoying since there's no matching touchend (filed at [1]).

All I can think of is to suppress the context menu popup if UIAccessibilityIsVoiceOverRunning() returns true, but that will break the context menu altogether for VoiceOver users. Boris, do you see this often?
Flags: needinfo?(dusek)
Not sure we have any good immediate options here, so bumping to 1.1.
(In reply to Brian Nicholson (:bnicholson) from comment #10)
> Boris, do you see this often?
often enough - e.g. wikipedia main page ("language chooser") - open the "English" link
I don't test with VoiceOver inside webpage content with VoiceOver too much to have a long list, but I had little problem to find a few examples when I tried.

> All I can think of is to suppress the context menu popup if
> UIAccessibilityIsVoiceOverRunning() returns true, but that will break the
> context menu altogether for VoiceOver users.

Seems that the issue is not present when running Firefox on iOS 9. Both cases (the "Mozilla Advocacy" link and the Wikipedia "English" link) I am aware of (I don't test inside webpages themselves with VoiceOver much) are present in iOS 8, but not in iOS 9 - in the latest master (a139c3a818fd4f16d12d2ea660d26a493140ccb9). Probably Webkit was fixed in this regard in iOS 9.

So a solution could be to disable it as you suggested, but only on iOS 8 using a runtime check for iOS version on which we are running.

(I did not test on iOS 9 with the Firefox version just *before* commit 43ccdf0a3257b171c8573b00608b2f3fe4a2fb4f (the one you fixed some of the occurrences of this issue), so cannot say whether removing that fix would keep things still working on iOS 9.)
Flags: needinfo?(dusek)
Since the workaround didn't work for all cases, let's just fallback to the default WKWebView context menu for these users.
Attachment #8647187 - Attachment is obsolete: true
Attachment #8653746 - Flags: review?(sarentz)
Comment on attachment 8653746 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/981

LGTM
Attachment #8653746 - Flags: review?(sarentz) → review+
https://github.com/mozilla/firefox-ios/commit/8f68746f105e72f8522eb0c670d870b86dcbaa40

v1.0: 3788ba0
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
(In reply to Brian Nicholson (:bnicholson) from comment #16)
> v1.0: 3788ba0

Hello Brian,

just tried the v1.0 branch with 3788ba0. Unfortunately things are not fixed in iOS 9.0 with it. It seems you will need to keep the "mouseup" event listeners, with the difference between iOS 8 and 9 being that on iOS 9, this will suffice to provide the correct behavior, but on iOS 8, it will not (and that is why we are turning the context menu completely off on iOS 8).

It also seems from this that the rdar you filed might be still valid for iOS 9.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Thanks for keeping an eye on this, Dusek. I merged the old fix back in: dfd639e

Hopefully everything works as expected now. If we still see issues on iOS 9, we should probably fall back to the default WKWebView context menu for VoiceOver users like we do on iOS 8.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
v1.0: af87b49
You need to log in before you can comment on or make changes to this bug.