Bug 1229129 solves single tap paragraph highlighting for people who aren't using VoiceOver; however, this means that VoiceOver users won't be able to use the context menu. We need to find a way to make the context menu we created accessible regardless.
Brian, could you write up some more details?
tracking-fxios: ? → +
Hardware: Other → All
It all starts with our custom context menu hack. WKWebView doesn't have a proper API for exposing a context menu, so we have to add touchstart/touchend to the content page to detect long presses, after which we show our own dialog. Apparently, there's a bug in WKWebView where the touchend event isn't fired if we're using VoiceOver (filed as https://openradar.appspot.com/radar?id=6618222514143232). That would cause the context menu to appear every time a link was clicked: since we would detect a touchstart but no corresponding touchend, it looked like the user's finger was being held down. Through experimentation, I found that mouseup *is* fired, so we used that as a workaround to detect when the finger is lifted in bug 1191687. Unfortunately, using mouseup introduced other regressions. For whatever reason, simply having a mouseup event listener registered on the page would cause elements to be highlighted on tap (bug 1229129). I think we also ran into issues where the context menu wasn't appearing on some pages. The fix for bug 1229129 was to simply disable the custom context menu for VoiceOver users, falling back to the built-in WKWebView context menu for those users. We still show the custom context menu for non-VoiceOver users. So that's where we are now, and this bug is about figuring out a way to bring back our custom context menu for VoiceOver users without breaking other things.
You need to log in before you can comment on or make changes to this bug.