Seems to be an issue on the content-service side:
https://en.wikipedia.org/api/rest_v1/page/mobile-html/I%27m_Glad_My_Mom_Died

The problem doesn't exist on https://en.wikipedia.org/api/rest_v1/page/html/I'm_Glad_My_Mom_Died and the underlying HTML from Parsoid is:

I<span typeof="mw:Entity">'</span>m Glad My Mom Died <span class="Z3988" title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&amp;rft.genre=book&amp;rft.btitle=&amp;rft.author=%5B%5BJennette+McCurdy%5D%5D&amp;rft.date=August+9%2C+2022&amp;rft.pub=%5B%5BSimon+%26+Schuster%5D%5D&amp;rft.pages=320"></span>

The PCS output is:

<caption class="infobox-title" style="font-size:125%; font-style:italic; padding-bottom:0.2em;">I<span>'</span>m Glad My Mom Died </caption>

There are no additional newlines in the PCS output.

This seems to be a CSS styling issue, and not a Parsoid/PCS bug. The root cause is this CSS rule:

.content .infobox > caption, .content .infobox > tbody {
  display: flex;
  flex-flow: column nowrap;
}

The flex layout has special handling for the children of the parent container (in this case the <caption>) but there are no children of the caption. Instead, any <span> or other tags, like <b> or <i>, are treated as the children and given a flex box layout inside of the caption.

The solution is either (1) fix the broken CSS rule, or (2) add a wrapper <span> inside the caption and including the entire title, so that portions of the title aren't broken up into separate flex box items.

Just noting that this does appears on the iOS app as well, as expected for it being that CSS issue.

@cscott whilse this has come back on our radar, I wanted to ask why is the parser rendering the apostrophe as <span typeof="mw:Entity">'</span> anyway?

This seems somewhat unnecessary.

Now affecting Minerva via WikimediaMessages and it's super visible as such.

I think there's two valid questions:

1. Why is Parsoid doing this? I think the answer is probably "we're marking up the difference between an attribute start/end text, an italic/bold, and an apostrophe". I'm not sure that's useful for read views, but it may be necessary for the whole 'turn HTML back into wikitext' thing. There are other cases it's affecting too, like colons (as in the merged task).
2. Is the flex on <caption> truly necessary? (The rest of the context of the relevant chunk of CSS is infobox mobile friendliness hackery.)

Hrm. This comes from the fact that expanding {{PAGENAME}} goes through CoreParserFunctions::pagename, which does escape wikitext on output.
At this point, we get the &#39; added to the string that gets parsed by Parsoid; and when we encounter an explicit entity on parsing, it gets wrapped inside a mw:Entity span for, as @Izno points out, round-tripping reasons. So its generation looks correct to me.

That said, it could be a reasonable thing to do to remove mw:Entity wrappers for read views - that's adding unnecessary bytes to the page. But if/when this comes, this will probably not be before we tackle the overall issue of "trying to reduce the size of the Parsoid read-views content" - we are discussing this these days (T272331 comes to mind), but I don't think we have yet a consensus, let alone plans and, while removing these would make sense in the context of an extra DOM pass that trims the HTML, I don't think we want to take the associated performance hit in the general case.

I believe that removing the flexon <caption> may be your best bet for now, assuming it doesn't trigger undesirable side effects. I suppose that adding a <span> wrapper in the <caption> as Scott mentions would also work, but that would probably require editing the master Infobox module, which, yeesh.

I'm consequently tempted to decline this issue; for now I'll keep it on Tracking on our board to give y'all some time to tell us what you think.

@Izno do you have an example of the WikimediaMessages use case? I haven't seen that one yet, I think.

In T372062#12120978, @ihurbain wrote:

I believe that removing the flexon <caption> may be your best bet for now, assuming it doesn't trigger undesirable side effects. I suppose that adding a <span> wrapper in the <caption> as Scott mentions would also work, but that would probably require editing the master Infobox module, which, yeesh.

I'm consequently tempted to decline this issue; for now I'll keep it on Tracking on our board to give y'all some time to tell us what you think.

@Izno do you have an example of the WikimediaMessages use case? I haven't seen that one yet, I think.

The flex described by cscott lives in WikimediaMessages , not onwiki etc (for some value of long-future yet). Both Minerva and (thankfully now) the apps use it as a dependency for aforementioned infobox hackery on mobile. Declining would be inappropriate in that case. If it can be removed from captions, it should be, which requires an upstream patch. Obviously someone frontend should do testing in the various places.

assuming it doesn't trigger undesirable side effects

Yes, I think this is an assumption. :) Unfortunately no documentation was provided that actually describes why caption was targeted. I can't think of content in caption that would require the treatment.

probably require editing the master Infobox module, which, yeesh.

This is actually trivial, adding a div just inside the <caption>, I just would rather fix the core issue, which is known but not its impacts. (And it doesn't fix the ~2k infoboxes which don't use the module, which is the vanishing minority.)

Change #1312505 had a related patch set uploaded (by Isabelle Hurbain-Palatin; author: Isabelle Hurbain-Palatin):

[mediawiki/core@master] Introduce a DeclutterParsoidOutput pass

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

Change #1312505 abandoned by Isabelle Hurbain-Palatin:

[mediawiki/core@master] Introduce a DeclutterParsoidOutput pass

Reason:

apparently we don't like this :P

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