Visit https://m.mediawiki.org/wiki/MediaWiki

Are you using Desktop view? Or Mobile view?
https://m.mediawiki.org/wiki/MediaWiki is the same as https://www.mediawiki.org/wiki/MediaWiki nowadays.

I’m using mobile mode.

Some pages on desktop mode have the same problem though.

This is not an issue in Firefox on the mobile website. On VPT there appears to be a belief this may be a Safari bug.

It's certainly happening in Safari on an iPad, in desktop mode. Also, I have Parsoid disabled

@OSleger-WMF are you sure it’s the same bug? I was also under this impression but it seems different since users report that they don’t see it just for interwiki links.

Parsoid output has protocol-relative links instead of normal relative links, e.g. <a href="//en.wikipedia.org/wiki/Foo"> instead of <a href="/wiki/Foo">. I wonder if that might be the cause? They should be recognized as the same link target, but maybe Safari handles this incorrectly.

For me, on my iPhone 12 mini, I can reproduce the bug on both Safari & Firefox. If I visit enwiki:Hampi and click around and come back, the links are all blue after all the clicking around. If i add "?useparsoid=0" to the links, the purple visited link color now shows up as expected. So, per @matmarex 's speculation above, it is possible something about Parsoid's href is causing Safari to not handle this properly. (EDIT: And, @OSleger-WMF tells me that on the iPhone, even Firefox uses Safari core underneath).

In T425211#12081228, @matmarex wrote:

Parsoid output has protocol-relative links instead of normal relative links, e.g. <a href="//en.wikipedia.org/wiki/Foo"> instead of <a href="/wiki/Foo">. I wonder if that might be the cause? They should be recognized as the same link target, but maybe Safari handles this incorrectly.

Feels like it’d be easy to check by making a demo page somewhere with all the different variants of outputting a link like this (relative ones could be supported in the demo by using <base> tag).

Also, I have made some experiment related to ":visited" pseudo-class within the safary, and it looks like it only assigns ":visited" pseudo-class to elements based on only pure html which came from server. Any JS or developer changes are not making link to aquire or lose a :visited" pseudo-class, no matter the change. So any JS solution will not work.

Can you make that page publicly available somewhere for others to test? There should be WMF-provided hosting on https://people.wikimedia.org IIRC

I am afraid, that I do not have access to that server, but I compacted my experiment into one file so anybody else can try / publish it.

I also uploaded it to: https://people.wikimedia.org/~osleger/safari_parsoid_test.html

Upstream bug report: https://bugs.webkit.org/show_bug.cgi?id=13755

In T425211#12082459, @ssastry wrote:

For me, on my iPhone 12 mini, I can reproduce the bug on both Safari & Firefox.

Beware that the only browser engine Apple allows on iPhone is Safari. Other browser apps distributed in the App Store (such as Firefox, Edge, and Chrome) are, unlike their counterparts on desktop and Android, reduced to mere UIs around an OS-bound frame running an inferior version of Safari ("WebView") which includes a version of the WebKit layout engine and JSC JavaScript engine that, among other differences, are slower than Safari and disables features such as WebRTC which Apple enables in Safari but forcefully keeps out of WebView-based browser apps. See also https://open-web-advocacy.org/walled-gardens-report/ and https://open-web-advocacy.org/press/.

So for the purposes of this task, it is "just" a Safari bug.

In T425211#12101710, @Krinkle wrote:

Upstream bug report: https://bugs.webkit.org/show_bug.cgi?id=13755

After my comment someone at Apple pulled it into their Radar system, and Anne started working on it. A fix has appeared! https://github.com/WebKit/WebKit/pull/69114

In T425211#12110633, @Krinkle wrote:

After my comment someone at Apple pulled it into their Radar system, and Anne started working on it. A fix has appeared! https://github.com/WebKit/WebKit/pull/69114

Nice work !

For everyone, this change likely already missed the upcoming late summer release of Safari 27, as 27 beta was cut before WWDC. So I suspect this will not land with consumers till november when 27.1 will be released.