Page MenuHomePhabricator

Missing active state on touch for hyperlinks in article namespace on iOS devices
Closed, ResolvedPublic2 Estimated Story Points

Description

Issue

While reading an article, if a user taps a bluelink in an article, the link turns yellow to show responsiveness. This is a accessibility feature as well as critical feedback. This feedback is missing on iOS devices. This is a regression or a change on iOS's part that we need accommodate

Steps to reproduce

  • Go to an article using iPhone (touch device) using safari or chrome
  • Tap on any blue link
  • The new article opens without any feedback that you have tapped a link, doesn't tell you which link you have tapped


example - no visible tap feedback

Happening on

  • iPhone X / iOS 11.0.1
  • MobileFrontend
  • Latest mobile safari
  • Latest chrome browser
  • Wikipedia native iOS app

Earlier expected behaviour

  • The link should turn yellow as soon as touchdown event is triggered

You can check how it should behave on Android devices. this is confirmed to be working on android

New expected behaviour

Use -webkit-tap-highlight-color property for <a> tags on articles

Value for the color #F5A623 at alpha 20 or rgba(245,166,35,0.2)

we will be just removing the transparent property and let the browser decide the default color. on iOS the color is black with opacity.

Mock

Relevant comments

We define

-webkit-tap-highlight-color: transparent;

(its defined inside skins.minerva.base.reset)

About body
Do it only for content hyperlinks for now. No change to UI.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 22 2018, 9:24 PM
Nirzar triaged this task as High priority.Feb 22 2018, 9:25 PM
Nirzar added subscribers: Jdlrobson, ovasileva, phuedx.
Niedzielski added a subscriber: Niedzielski.EditedFeb 22 2018, 9:28 PM

This issue does not occur on a Google Pixel XL or Chromium device emulation (Nexus 5X, iPhone 7, iPhone X).

Nirzar raised the priority of this task from High to Needs Triage.Feb 22 2018, 9:32 PM
cmadeo added a subscriber: cmadeo.Feb 22 2018, 9:36 PM
Mhurd added a subscriber: Mhurd.Feb 22 2018, 9:44 PM

@Nirzar hmm not sure this is a regression or result of any recent change. I don't recall us ever having this, but we can definitely take a peek! :)

you sure? I definitely remember seeing yellow color when you touch bluelinks in iOS app. wondering.. why are they yellow? because someone in the 2000s decided to make :active yellow. never liked it but it was the only feedback

The code is defined here: https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.content.styles/links.less
I'm not sure why this would be overridden in iOS.

Safari 11.0.3 desktop is working fine for me... so this is definitely something iOS specific.
Can someone with an iOS device debug this via Safari developer tools and work out what's happening?

Mhurd claimed this task.Feb 22 2018, 9:54 PM
Mhurd removed Mhurd as the assignee of this task.Feb 22 2018, 10:00 PM

@Nirzar Oops sorry I thought this was app-specific!

Tested on iOS Chrome and Safari and not seeing yellow on either...

Jdlrobson added a subscriber: ABorbaWMF.

@ABorbaWMF are you able to replicate this? I can't replicate on browserstack so this would need a real device.
@Nirzar have you double checked if this occurs when anonymous?

@Jdlrobson I can replicate this one on iPhone 7 so far both logged in and out. I can try more devices as well. There are a couple of iOS devices at the office as well in the cabinet. Will send the URL.

JoeWalsh added a subscriber: JoeWalsh.EditedFeb 22 2018, 10:49 PM

@Jdlrobson on an iOS device in Safari, en.m.wikipedia.org has the same problem as the iOS app - the links never get to the :active state.

The workaround in the link monte posted (adding ontouchstart="" to the body tag) highlights the link temporarily. Not sure why that works, but there's no guarantee it'll continue to work.

The hackaround that I have working in the app is to add a separate .active css class, add it to the classList of the link on click, then remove it when the navigation completes.

JoeWalsh added a comment.EditedFeb 22 2018, 11:05 PM

Seems like an issue that should be fixed in WebKit, WKWebView, and/or mobile Safari

Apple News & Apple.com both use -webkit-tap-highlight-color: to show which link is active while the touch is active. When the touch is lifted to complete the navigation, the highlight goes away. Looks like this:

I tried it in our app with the yellow at 50% alpha:

Apple.com also uses :hover to add an underline for the navigation links at the bottom of the page. In Safari on iOS, these links get underlined on tap and stay underlined throughout the navigation action. I added a :hover state with a text color to the links in the app and the state persisted similar to :active on desktop. However, when the user taps back to the article they navigated away from, the state persists and the link is still the active color. There might be a way to programmatically clear this, but I didn't explore further. It seems managing our own class would be preferable to depending on :hover continuing to behave this way on mobile.

TL;DR three possible ways we could fix this in the iOS app:

  • Match Apple News - show a highlight box only while the touch is active that disappears when the touch is lifted (set -webkit-tap-highlight-color:)
  • Match desktop - change the text color after the link is activated and while the view is being animated away (set/unset our own active class, currently implemented in beta build 1354)
  • Implement both solutions (show a highlight box while the touch is active and change the text color when the navigation is activated)

so we used to use color prop and not define -webkit-tap-highlight... I have no idea who took that call years ago. I don't mind moving to using webkit-tap-highlight now.

The :hover state usage on tap on iOS is very unreliable. it applies the hover (underline) on tap 1 in 10 times. at least for me.

Let's define -webkit-tap-highlight in our css, that seems to be most promising and all accessibility guidelines suggest we shouldn't be removing -webkit-tap-highlight-color

#F5A623 at alpha 20 
245/166/35/0.2
Nirzar renamed this task from [Bug] [Regression] Missing active state on touch for hyperlinks in article namespace on iOS devices to Missing active state on touch for hyperlinks in article namespace on iOS devices.Feb 23 2018, 4:25 PM
Nirzar updated the task description. (Show Details)
ovasileva triaged this task as High priority.Feb 23 2018, 7:14 PM
Nirzar updated the task description. (Show Details)Feb 23 2018, 7:24 PM

We define

-webkit-tap-highlight-color: transparent;

always have.
(its defined inside skins.minerva.base.reset)

I'm confused, given I cannot replicate in mobile web, is this an app only issue?

Not an app only issue. This is happening on web confirmed by Anthony, joe, Monte, and i. Joe is fixing it in the override css for app. The WebKit taphighlight is not visible on iOS touch devices Because of the transparent property. I have changed the task from a bug to change. We need to remove the transparent and add the color value given in the task description. Reason we are removing something we have always had is because iOS probably stopped using :active state for taps. So we have to use the official tap highlight property.

Jdrewniak updated the task description. (Show Details)Feb 26 2018, 9:59 AM
Jdrewniak updated the task description. (Show Details)
Jdrewniak added a subscriber: Jdrewniak.EditedFeb 26 2018, 11:23 AM

I've tested this change by just changing

-webkit-tap-highlight-color: rgba(245,166,35,0.2);

The results are very subtle. Sometimes on my iPhone 6S, with a very quick tap, the effect is not visible at all, but that's probably a combination of very quick tapping and changes to the (used to be 300ms) tap delay on iOS.

@Nirzar should we reconsider placing this on the body element? It effects taps on all tappable things, like the sidebar links and buttons (as shown in the video below). Maybe we should just place this effect on content links?

(video link)
https://drive.google.com/file/d/1Bo7yFlGNZ3L_bKkdtVjV3abBgPzInIKc/view?usp=sharing

About body
No, we need to keep it only for hyperlinks for now. no change to UI.

About subtly
The alpha used here is equivalent of default tap-highlight-color, yellow makes it more subtle than black (default) at same alpha. Can we put this on staging so I can take a look? I will test it on old androids with low color depth screen

ovasileva set the point value for this task to 2.Feb 27 2018, 5:17 PM
Jhernandez updated the task description. (Show Details)Feb 27 2018, 5:20 PM
Nirzar updated the task description. (Show Details)Mar 1 2018, 2:11 AM

Change 415556 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/skins/MinervaNeue@master] Removing tap-highlight override for iOS

https://gerrit.wikimedia.org/r/415556

Jdrewniak updated the task description. (Show Details)Mar 1 2018, 12:42 PM
Jdrewniak updated the task description. (Show Details)

Change 415556 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Removing tap-highlight override for iOS

https://gerrit.wikimedia.org/r/415556

Jdlrobson reassigned this task from Jdrewniak to ABorbaWMF.Mar 1 2018, 7:12 PM

Can be tested on the beta cluster

@Jdlrobson, This is still reproducing on Beta for me.

Looks like the beta cluster is running old code.
Can you test on reading web staging? (word of warning: this is currently configured to use Hindi Wikipedia but that should not impact your testing).

tested on staging, this is getting applied to all the links and buttons including the UI. i think that's because we removed the property completely. we might need to do a {-webkit-tap-highlight-color:default; } override for article hyperlinks and keep the transparent property for body.

just my opinion, but shouldn't UI elements provide some tap feedback as well? Many times the ui action, like switches on the settings page, are not guaranteed to provide immediate feedback (actions are carried out asynchronously, or might be waiting for a script to load) so giving users assurance that they tapped the thing seems reasonable to me.

Working on staging. I am seeing the same thing as Nirzar and I agree with Jan. It's nice that more things are highlighting :)

I'll move this ticket to signoff and maybe we can revisit specific highlighting stuff again. I hope that works, if not revert away.

@Nirzar @alexhollender @Jdrewniak We found this in Needs More Work during standup, recalling that it was in signoff but a design issue sent it back, but not much more than that. Can any of you clarify whether or not this task is ready for signoff, and if not, what is needed? :)

@alexhollender and I are working on coming up with our options. we identified some trade offs as the change intended here is getting applied to all interactive elements and not only hyperlinks.

We can stall this if that helps keep the board clean. but in needs more work as in, needs more work from design

UPDATE: after more discussion, we have decided this change should go live. we will be creating some design debt and follow ups. for now I can confirm this should get merged.


For the curious:
The discussion involved comparing the trade offs of taking control of the touch down event using :active state vs. OS handling it. consistency of this interaction on other platforms like android is of a concern. android will still use :active color yellow

the follow up for this task would include design team's preference for event-feedback for this prominent element.

Also maybe worth noting: with this approach any styling that targets :active (for example the styling we've got for mw-ui-button:focus) will be ignored by iOS browsers. It seems like there are one or two variations on a workaround for this, however they are hacky — both described here.

This comment was removed by alexhollender.