This caused a regression in Parsoid; two different patches above to resolve it.

Ok, this makes more sense that a JS interaction would cause memory exhaustion (vs just a particular magic sequence of HTML).

There's the potential to break various parser tests that hardcode a file URL. I don't think this will be a big concern in practice, but something to look out for.

It appears at the moment for these "html heading" tags we are wrapping them but not including them in the TOC, whereas we want to *not* wrap them but *include* them in the TOC.

A quick test seems to indicate that both Parsoid and the legacy parser use the .textContent of the HTML included in the heading to generate the TOC text (and presumably ID): https://en.wikipedia.org/w/index.php?title=User_talk:Cscott/Toc&oldid=1356567473

Does this trigger with using "desktop" mode on iOS Safari, but with useparsoid=1? My assumption is that this is a MobileFrontEnd bug, not necessarily a Parsoid bug.

This was a category breaking a wikilink, like:

[http://example.com/foo[[Category:Bar]].mp3 caption]

This is unsupported wiki syntax, that happened to work with the legacy parser because it stripped categories.

@Djido We should be honoring __NOCONTENTCONVERT__ on table of contents and the content, and __NOTITLECONVERT__ on the displayed title now (in 1.47.0-wmf.3, which should be on sr.wikipedia.org tomorrow).

In T19006#11923153, @matmarex wrote:

IMO the root of the problem is that Title::getFragment() (and also related lower-level interfaces, like Parsoid's LinkTarget::getFragment()) does not distinguish between no fragment and empty fragment. As a result we can't distinguish a completely empty title (which should be invalid, unless maybe T374555 changes something here) from a title with an empty fragment (which represents a link to a section within a page).

I think that's fixable, although it will take some effort. Start by changing these interfaces: https://codesearch.wmcloud.org/search/?q=public+function+getFragment\(\)%3A+string to return ?string instead of string, then review all of the code to return null for no fragment and '' for empty fragment…

Thanks! I'll give it a few more days to collect comments, then merge it.

Is https://www.mediawiki.org/wiki/VisualEditor/Real-time_collaboration / https://www.mediawiki.org/wiki/Extension:CollabPads an option?

I've got an implementation which seems to work for parser tests: it uses the phpunit:config target to generate a tests/phpunit/gen/ParserTest_*_Test.php class for every parser test file; that class then drives the parser test process using an ordinary data provider and the setUpBeforeClass and tearDownAfterClass handlers.

Can you point to a conversation on wiki where we have some community consensus and/or spell-checking? I've gotten in trouble in the past for merging these when it turned out there wasn't community consensus on the translations, so I like to have some community review before merging.

In T379645#10534012, @jhsoby wrote:

Another con: An article on another wiki that you've already visited doesn't get :visited styling when the href contains spaces instead of underscores.

Maybe the interwiki table needs a switch for whether or not the target title should be treated like a MediaWiki title? (After all, the vast majority of the interwiki link targets that are actually used – especially when you consider interlanguage links – go to MediaWiki wikis.)

We are deprecating this library, it has been replaced with an implementation in core. I don't object to creating a tag, but given the status of the library we could also just tag Content-Transform-Team (and/or archive the project).

I thought there was some client-side JS involved here as well to load the images as the page becomes visible? Is it really just an attribute which is needed?

POC patch here: POC: show markdown output for HTML (1270040) · Gerrit Code Review

This has been deployed. https://logstash.wikimedia.org/goto/e61c8e222ac0415fedfd7d1f8792b100 showed 330,573 instances of this log over the past 24 hours, but none since deploying the revert.

@MGChecker i'll try to backport 1286508 in a few minutes.

I think as a start we could make the extra variants available only via mediawiki configuration option, so that we can enable them on wikisource but not on the other projects (wikipedia, other sister projects).

Probably some fix needed like https://it.wikipedia.org/w/index.php?title=Modulo%3AProtezione&diff=146699469&oldid=130072618

Is this still blocked, or can we move ahead with this?

I think we should just check this against VisualEditor and against the ParsoidLanguageConverter code in core, which also deal with red links. But I'd say from a design perspective we shouldn't be relying on any specific URL (either for red links or from actual media). Parsoid treats the URL provided as a black box, and we recognize the red link (or the media source) from other attributes in the HTML (resource, I think, but I'm writing this without double-checking the HTML).

In T425364#11895809, @Izno wrote:

In T425364#11895381, @SomeRandomDeveloper wrote:

This is caused by the selector at https://en.wikipedia.org/w/index.php?title=Module:Hatnote/styles.css&oldid=1320445320#L-19, which doesn't apply on parsoid, as there are no link elements for the deduplicated styles between the divs. There should probably also be a selector for .hatnote + .hatnote that applies the same styles.

The actual issue was caused by T378906: Categories as link tags cause navboxes to have a rendering difference. I will probably need to fix onwiki with the new approach there, but I don't want to do that until the new approach is live (circa Thursday this week).

This will require a CSS fix in srwiki, although there are some tweaks which are still rolling out in Parsoid to mitigate to some degree. We expect next train (next week) will have some final pieces of the puzzle, and we will document how to update the CSS on https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Instructions_for_editors#Adapt_CSS once that rolls out.

(We're assuming that "rollback" means "backport" here.)

We're going to untag Content-Transform-Team from this issue as it is being fixed in Cite/VE. Feel free to retag us or find us on slack etc if you need more assistance from our team.

The spec for what Parsoid generates inside a transcluded block is https://www.mediawiki.org/wiki/Specs/HTML/2.8.0#Contents_of_transcluded_blocks so it should be possible to use that spec to reliably detect a <references/> node by the typeof="mw:Extension/references". We believe that WMDE is working on a path to make the detection of <references> inside VE more robust.

I'll note briefly that since T273237 was resolved (5 years ago, in 2021), nothing seems to break if the main branch is used for *library* code. There are a number of libraries which have been using branches named main for about five years without setting anything on fire or terrifying new contributors. Bcp47Code is one, as is JsonCodec, https://gerrit.wikimedia.org/r/q/project:mediawiki/libs/IDLeDOM, https://gerrit.wikimedia.org/r/q/project:mediawiki/libs/WebIDL etc etc.

See also T425606: Create project tag for `wikimedia/zest` composer package, for the related zest library.

Parsoid supports LanguageConverter in production now: T380517: Make Parsoid language conversion into an OutputTransform pass

Some other URLs associated with this crash, which are more useful than trying to chase down the title involved in the ParsoidCachePrewarmJob:

• https://th.wiktionary.org/w/index.php?mobileaction=toggle_view_mobile&title=%E0%B9%81%E0%B8%A1%E0%B9%88%E0%B9%81%E0%B8%9A%E0%B8%9A:bot
• https://www.wikifunctions.org/w/index.php?direction=next&oldid=3759&title=Template:Documentation_subpage
• https://lb.wiktionary.org/wiki/Schabloun:Bot
• https://hi.wiktionary.org/wiki/%E0%A4%B8%E0%A4%BE%E0%A4%81%E0%A4%9A%E0%A4%BE:Bot

Related to T380979: Block nesting <ref> tags in the details syntax perhaps?

We can rephrase that. My intention was that step was "make use of the deprecated module visible to editors". I think you suggested adding some sort of warning to the console when skins.legacythumbs.deprecated was loaded.

oh, right, this is probably a side-effect of T373384: Parsoid doesn't properly handle double-underscore magic words.

This works now.

Rough plan:

• Implement {{#media:content=....}} as a new parser function (T318433#10397735) to allow migration of content using the existing legacy DOM structure.
• Document new parser function & recommended conversion for editors on wiki, send note to Tech News with deadline for conversion
• Add something like if ( (strpos( $out->getHtml(), 'thumbinner' ) ) { $out->addModule('skins.legacythumbs.deprecated'); } (similar pattern as used for mw-ui-button)
• Set $wgUseLegacyMediaStyles = false in production
• Remove this code from 1.47