Parsoid usually sets a <base href> in the document, but when embedded page in an article this doesn't exist so our links are all broken.
See the [[Opportunities for the Content Transform Team]] link at https://en.wikipedia.org/wiki/User:Cscott/Ideas?useparsoid=1
EDIT: After adding the missing <base href>, all TOC links are broken; see comment below.
I think we should fix this sooner than later .. I suspect officewiki has subpage links.
The solution to this might also fix T310520, if we're implementing a parsoid-read-views-specific href rewriting postprocessing pass.
Things to be careful of:
Change 973361 had a related patch set uploaded (by Isabelle Hurbain-Palatin; author: C. Scott Ananian):
[mediawiki/core@master] Fix Parsoid <base href>
I merged and pushed to beta, but TOC link fragments are broken (see https://en.wikipedia.beta.wmflabs.org/wiki/African_linsang?useparsoid=1 )
Change 975051 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@master] [parsoid] Fix Parsoid relative links
Change 975081 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@master] [parsoid] Fix Parsoid relative links, take 2
Change 975051 merged by jenkins-bot:
[mediawiki/core@master] [parsoid] Fix Parsoid relative links
Change 975081 abandoned by C. Scott Ananian:
[mediawiki/core@master] [parsoid] Fix Parsoid relative links, take 2
Reason:
Abandoned in favor of I60165a9946a35cfb42a78ed2f833c34570fefffc
Change 975596 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
[mediawiki/core@wmf/1.42.0-wmf.5] [parsoid] Fix Parsoid relative links
Change 975596 merged by jenkins-bot:
[mediawiki/core@wmf/1.42.0-wmf.5] [parsoid] Fix Parsoid relative links
Mentioned in SAL (#wikimedia-operations) [2023-11-20T22:27:22Z] <catrope@deploy2002> Started scap: Backport for [[gerrit:975596|[parsoid] Fix Parsoid relative links (T350952)]]
Mentioned in SAL (#wikimedia-operations) [2023-11-20T22:28:40Z] <catrope@deploy2002> catrope and cscott: Backport for [[gerrit:975596|[parsoid] Fix Parsoid relative links (T350952)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2023-11-20T22:46:54Z] <catrope@deploy2002> Finished scap: Backport for [[gerrit:975596|[parsoid] Fix Parsoid relative links (T350952)]] (duration: 19m 32s)
Merged and backported to production; you might need ?action=purge on Parsoid Read Views pages for a while to get the sidebar links correct, since we need to regenerate the page without the <base href> in the ParserOutput::addHeadItems.
So, as part of reviewing T425211: Link colours don't change to purple in Safari on Parsoid-served pageviews, we decided to look at why we decided to introduce protocol-relative links instead of either retaining Parsoid's (the library) "./" relative links OR using absolute links, and this task is the source of those changes. I'm going to summarize the info I gathered so far (since I didn't remember the details and we don't want to go digging again).
My recollection is that it wasn't just TOCs, a lot of skin code and user gadgets also assumed that the base href of the page was unmodified. Setting the base href to something "unexpected" broke a *lot* of things on subpages; the TOC links were just the thing which got written into the phab task.
We could have tweaked parsoid to use ../ relative prefixes instead of converting to absolute links. We'd done that a lot during the early days of VE and had some reasonable confidence that VE would just ignore any (..?/)* prefix. But this was considered a breaking DOM change, even though it probably would have been the wiser long-term approach. We went back and forth between ./ and ../ many times during early VE development, and I don't remember all the factors that led us to where we are now. This would have been a more disruptive change. Also, it would break 3rd-party wikis which use a ?title=%s URL pattern. T310520: Parsoid content not compatible with `index.php?title=` URLs/T270219: VisualEditor does not support wikis without short URLs
The "convert to absolute URLs" code was already in the postprocessing pipeline, and we were backporting fixes; in that environment "just" using the existing pass to convert all of the URLs seemed like the safer immediate fix.
wrt protocol-relative URLs: in this case Parsoid (and the postprocessing code) is just following the mediawiki default. There were good reasons to use protocol-relative URLs when not all WMF wikis were https-only. Those reasons are years in the past, and WMF could/should probably change its defaults to http (T54253: Protocol-relative URLs are poorly supported or unsupported by a number of HTTP clients). That's a mediawiki-config change, though, not a Parsoid change (T118413: Wikimedia wikis should use https:// in $wgServer) and there's a bunch of code that needs to be fixed before we can do this: T118413#10973765