Using PROTO_CANONICAL will use the full https:// prefix instead of the "protocol-relative" // prefix for wikilinks. This costs bytes (!) but works around Safari bugs with "visited" status for protocol-relative links (T425211: Link colours don't change to purple in Safari on Parsoid-served pageviews).
Only Parsoid output goes through the ExpandRelativeAttrs post-processing stage. Some discussion of alternatives is in T350952#12091784.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In Progress | BUG REPORT | None | T425211 Link colours don't change to purple in Safari on Parsoid-served pageviews | ||
| Resolved | cscott | T431358 Use PROTO_CANONICAL instead of PROTO_RELATIVE in ExpandRelativeAttrs |
Change #1307864 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@master] Use PROTO_CANONICAL for Parsoid wikilink href URLs
Change #1307884 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@master] ParsoidParser: store base href in the extension data
Change #1307864 merged by jenkins-bot:
[mediawiki/core@master] Use PROTO_CANONICAL for Parsoid wikilink href URLs
This costs bytes (!) but works around Safari bugs with "visited" status for protocol-relative links (T54253)
There are no matches for any of "visit", "safari", "webkit", "apple", or "mac" in the description or comments on task T54253. Where can I find more about this bug? If it is still reproducible, I'd like to make sure it is reported upstream.
T425211: Link colours don't change to purple in Safari on Parsoid-served pageviews is where this bug exploration started and landed here. (<internal-slack-ref>There is also a slack thread in the Content-Platform-Team channel that links to a enwiki:VPT discussion about this safari bug</internal-slack-ref>)
Please do a User-notice if you end up merging this change, as a number of user scripts already had to accommodate for the new Parsoid link syntax, most recently https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-Certes-20260704221300-DisamAssist_behaviour_changed_under_Parsoid so changing it again without a proper announcement would end up surfacing more issues (to me both types of links are not that great but what can we do).
We were already discussing that we would need to notify users, but you were one step ahead of us in adding the User-notice tag. :)
Hello! I am responding to the user notice tag. How should we word this announcement, and which edition are we publishing this in?
"To work around a Safari bug (see [[phab:T425211]]), on Parsoid-enabled wikis, wikilink hrefs now use absolute urls instead of protocol-relative urls. REST API output remains unchanged and continue to use protocol-relative urls. Gadgets, user scripts, bots, and CSS might need to adapted if they relied on the presence of protocol-relative urls in wikilink hrefs." Let me know if this is too long and I can look for a shorter version.
Some more discussion on mastodon at https://hachyderm.io/@krinkle@fosstodon.org/116886539947537185 and https://kolektiva.social/@cscott/116937539576605366.
In theory we could move Parsoid back to relative links, but there's no good <base href> for those relative links which would keep links correct on both REST APIs (where the page AC/DC is https://en.wikipedia.org/w/rest.php/v1/page/AC%2FDC/html ) and article views (where the page is https://en.wikipedia.org/wiki/AC/DC ). Wikis which don't use short URLs ( https://www.mediawiki.org/wiki/Manual:Short_URL ) are a problem for both, which is fundamentally the reason we do the ExpandRelativeAttrs pass in core. It would be nice if we could skip that path for wikis which use short urls, but that would require changing the base href and adding ../ prefixes to Parsoid's URLs.
Change #1307884 merged by jenkins-bot:
[mediawiki/core@master] ParsoidParser: store base href in the extension data
