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

@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?

@Jdlrobson checking...

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

Hmm... perhaps related to https://stackoverflow.com/a/33681490/135557 ?

@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.

@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.

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

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.

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

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

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

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

@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.