considering they already exist for the paged tiff handler, but not yet in core ?
https://www.mediawiki.org/wiki/Extension:PagedTiffHandler

In T208578#9239139, @TheDJ wrote:

@Arlolra I was thinking about perhaps reusing the lossless/lossy keywords for the SVG Handler in order to allow people to choose between the plain SVG and the PNG version. Would that require any parsoid adaptions, considering they already exist for the paged tiff handler, but not yet in core ?

T346805#9267483 was re-uploaded because the current solution was shown to break template wrapping continuity in https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/966649

As far as I can tell, if a gallery isn't edited, the data-mw is left as is on the <video> tag. If the gallery is edited in VE, the <video> element becomes an <img> where an alt attribute is valid.

It's unfortunate that galleries are so tied-together that even editing only a different thumb within it seemed to be enough to lose the video's data-mw on submission.

My patch fixes the latter issue, because it reads the alt from data-mw and VE's existing behavior then puts it (incorrectly, but Parsoid reads it) into an alt on the <video>.

Parsoid has the ability to avoid this normalization now,

1. Parsoid ignores the data-mw attribute that it currently outputs on videos that have alternate text if we submit it. That’s why there’s always a dirty-diff on those pages even when selser should mean that VE's output is ignored. This is (probably) T214603.

From slack,

Presumably this is the result of some patches being applied for T346657

It looks like, around the deploy of 1.40.0/wmf.27, the mean init time for oldid reduced to being the same as for wt. Parsoid changes in that deploy were only in test directories and git diff origin/wmf/1.40.0-wmf.26 origin/wmf/1.40.0-wmf.27 includes/Rest isn't turning up anything obvious.

Based on the past few comments, it's probably safe to say we aren't getting cached responses so there's nothing to do here.

Now that it has been a week since the fix in T339365#9229478 has been deployed, I took a look at the timed metrics in T339365#9229984 and T339365#9232593 and they seemed comparable to the old ones. As was described, some of the differences could be because of the differences in sets of pages processed, either due to the incompleteness of the old metrics or the inclusion of cache hits in them, or init time or bloat from json serialization. Nothing stands out as worth investigation beyond what was already done above.

As far as rt testing is concerned, the oldid is not set when making the wt2html request, so that's not an issue there,
https://github.com/wikimedia/mediawiki-services-parsoid/blob/master/bin/roundtrip-test.js#L825-L831

that should make it not cacheable already,
https://github.com/wikimedia/mediawiki/blob/master/includes/Rest/Handler/Helper/HtmlOutputRendererHelper.php#L750

Oh, so first step is already to fetch the wikitext which we'll need for selser to work,
https://github.com/wikimedia/mediawiki-services-parsoid/blob/master/bin/roundtrip-test.js#L800

Parsoid's API tests call an API which is no longer part of the Parsoid library, but instead is provided by core.

I made this edit based on T341736#9247790,
https://commons.wikimedia.org/w/index.php?title=MediaWiki%3AGadget-QICvote.js&diff=811640316&oldid=811029147

Taking a fresh look today, I noticed,

Another issue with the gadget is,

I made this edit but it didn't make any difference,
https://commons.wikimedia.org/w/index.php?title=MediaWiki%3AGadget-QICvote.js&diff=810836824&oldid=782872580

@Tagooty Sorry, this task was highlighting specific breakage as a result of T314318. That change has been deployed for quite some time now so I'm going assume any new breakage is unrelated.

Please don't revert the changes, which have been helpful overall.

The issue is that these noinclude tags are in the table (row) attribute position (as you've discovered in the workarounds) and Parsoid tokenizes noincludes as balanced units, so the entire noinclude tag and its contents, including the table end tag, gets hoisted into the attributes (and anything else on the closing noinclude tag's line)

Create new grafana dashboards with the new .entry prefixed metrics and compare the dashboards for accuracy

Post-deploy, I ran ?action=purge on https://de.wikivoyage.org/wiki/Vorlage:Rail-interchange/Doku/Mitteleuropa and it cleared the lints from the category https://de.wikivoyage.org/wiki/Spezial:LintErrors/bogus-image-options

Create new grafana dashboards with the new .entry prefixed metrics and compare the dashboards for accuracy

The above patch fixes this issue but since there isn't consensus, I'm abandoning it for now. It can be restored if it's desired.

After this edit,
https://www.mediawiki.org/w/index.php?title=User%3AArlolra%2Fsandbox&diff=6136419&oldid=6136403

With this edit,
https://www.mediawiki.org/w/index.php?title=User%3AArlolra%2Fsandbox&diff=6136403&oldid=6006024

So that is a bug/known difference that Parsoid doesn't respect the user setting but that's generally been by design to this point and something that needs to be examined outside of this issue.

In a new session where I'm signed out, both the legacy rendering and parsoid set the width to 220. Are you signed in with a specific user setting?

In T345701#9204868, @Arlolra wrote:

Alas, this is going to need a new release of Timestamp similar to T329594

There's a few places to update,
https://codesearch-beta.wmcloud.org/search/?q=wikimedia%2Ftimestamp&files=composer.json&excludeFiles=&repos=

What's left to do here is,

In T305210#8966699, @TheDJ wrote:

• mwtitle and mwprovider: needed to make it easier to find the accompanying description page. I do believe that parsoid has some of this info as well on images and I know the MultimediaViewer infers this information from the image url, so perhaps this should be standardised ?

In T305210#8966699, @TheDJ wrote:

• Optional data-transcodekey: this is an identifier for the type of derivative source. It is present on all derivatives (transcodes) of an a/v item (source), but not on the original source. Generally the original source is present in the html, but this is not required and sometimes there is only an original and no derivative.

Note the File:Undefined from https://it.wikipedia.org/wiki/Timor_Est?useparsoid=1 while verifying T346703#9204822

Alas, this is going to need a new release of Timestamp similar to T329594

The train has reached itwiki and the TMH player is now loaded on,
https://it.wikipedia.org/wiki/Timor_Est?useparsoid=1

An attempt at this was started in,
https://github.com/wikimedia/mediawiki-services-parsoid/commit/55da3090d0e7faa49e40a5bce0f68634fea5fc83

@phuedx Thank you

It looks like the question mark is forcing this as an extlink,