In T418519#12390058, @Jdlrobson-WMF wrote:

@ABreault-WMF this appears to be caused by the position: relative rule added in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/28062181f9b2b27ab5ad0804a0f2c7db40e5fa11 you

Post-deploy, this seems fixed
https://en.wikipedia.org/w/index.php?title=User:ABreault_(WMF)/sandbox&oldid=1378665112?useparsoid=1

In T439393#12370802, @Physikerwelt wrote:

If you have any idea who could review it, I would highly appreciate your suggestions.

@Thilio I'm reassigning to myself since I've uploaded a fix. Sorry to have stepped on your toes, hopefully you didn't spend too much time on this.

When the method was added to LinkRenderer, the preference was for it to by not nullable. See the discussion at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1000043/9/includes/linker/LinkRenderer.php

In T436930#12357660, @Kallichore wrote:

I noticed that there is no "status 500" anymore for https://de.wikipedia.org/api/rest_v1/page/media-list/Bremen . There is also no problem in the Android app anymore for this case. I also checked the other exemples in this thread: the problem appears to be fixed.

I am not sure about the interpretation: has the "merge to master" alone fixed the problem (without backport?) or is there another explanation?

In T436930#12355790, @TheDJ wrote:

I think the question is, do we change the html of the frameless mode of Kartographer to emulate the frameless mode of mw:File media ?

Looks like the original issue was fixed by https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1321634 but the underscore issue from T423782#12301488 remains

Whoops, sorry

Also mentioned at https://www.mediawiki.org/w/index.php?title=Talk%3AParsoid%2FParser_Unification%2FKnown_Issues&diff=next#Section_only_links_breaking_for_some_templates

From T378906, it seems like maybe these spans should have an mw-empty-elt class so the selectors can be qualified

The index page has content wrapped in a poem,

These now render the same
https://en.wikipedia.org/w/index.php?title=User:GrandEscogriffe/sandbox&oldid=1369849896&useparsoid=0
https://en.wikipedia.org/w/index.php?title=User:GrandEscogriffe/sandbox&oldid=1369849896&useparsoid=1

See T65904 and other linked tasks there

Holding eowikisource back for T426752: eowikisource: css mismatch

In T432547#12244196, @Kallichore wrote:

I cannot observe any effect of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1327128 , which should be active on those Wikis in my understanding.

Nothing was deployed this week.

In T420668#12234743, @Krinkle wrote:

Oh, I assumed it woud have been one of the first.

I can't reproduce this. mediawiki.org uses Parsoid.

Thank you for providing the context

Curious, where and when is this used?

https://prv-target-tests.wmcloud.org/diff/kuwiki.ku-arab/Kurd
https://prv-target-tests.wmcloud.org/diff/kuwiki.ku-arab/Neol%C3%AEt%C3%AEk

The assumption here is that, because of rightmost wins, the preprocessor doesn't recognize this as a wikilink but then the second phase parsing of the legacy parser parses it as one anyways, whereas Parsoid tokenizing matches the preprocessor. I think there are tests that cover this and we're likely to decline but should be verified.