@Jdlrobson, this does not seem to be specific to the main page:

This and all the other mobile web tasks filed by you and Jon are all blocked on T269499: [Epic] Make MobileFrontend compatible with Parsoid HTML.

I'm curious why this one only happens on the main page. I wasn't able to replicate it on other pages.

The LazyImageTransform.php transform appears to be creating two lazy-image-placeholder elements when given the new parser HTML.

Change 1010950 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/MobileFrontend@master] [WIP] Account for Parsoid sections when applying LazyImageTransform

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

The issue is, as the patch above points out, Parsoid does its own section wrapping (maybe MakeSectionsTransform is redundant) and those sections can be nested, which LazyImageTransform::apply doesn't account for. The transform is applied multiple times to the nested sections. It's reproducible on,

== one ==

=== two ===

[[File:Nested.jpg|thumb|123]]

https://en.m.wikipedia.org/w/index.php?title=User:ABreault_(WMF)/sandbox&oldid=1213577888&useparsoid=1

Hey I looked at @ABreault-WMF as part of T359001 and I think the fix there resolves this issue.
I think as a short term fix we could add the code here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1010996/2/includes/Transforms/MakeSectionsTransform.php to address this problem and other related issues.

For longer term fix, I think getting section collapsing to work on MobileFrontend will require rethinking that feature but I think if we can avoid modifying the HTML further that would be ideal.

I don't think that patch fixes this issue. It does help in that the check ( $parent->getAttribute( 'id' ) !== 'mf-section-0' ) in the patch above can be removed.

My understanding is the patch you linked to will skip the MakeSectionTransform transform for Parsoid content, because sections are already present.

However, the issue here is that Parsoid's sections can be nested (see T358980#9628776 for test case) and the LazyImageTransform is applied to every section, and so the images in nested sections get applied multiple times.

You'll still need to patch above but it can be rebased on yours and cleaned up. Happy to do that if you want.

My understanding is the patch you linked to will skip the MakeSectionTransform transform for Parsoid content, because sections are already present.

Correct.

However, the issue here is that Parsoid's sections can be nested (see T358980#9628776 for test case) and the LazyImageTransform is applied to every section, and so the images in nested sections get applied multiple times.

Ah I see. I hadn't considered nested sections.

You'll still need to patch above but it can be rebased on yours and cleaned up. Happy to do that if you want.

Subbu mentioned there might be a more modern way to make post-cache transformations. Is there any interest in having a lazy loading transform somewhere other than MobileFrontend. Thinking ahead one day it should be used for desktop: T148047.

You'll still need to patch above but it can be rebased on yours and cleaned up. Happy to do that if you want.

That's done in PS4 and seems pretty straightforward,
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1010950/4/includes/Transforms/LazyImageTransform.php

Subbu mentioned there might be a more modern way to make post-cache transformations. Is there any interest in having a lazy loading transform somewhere other than MobileFrontend.

I imagine he was referring to this pipeline,
https://github.com/wikimedia/mediawiki/blob/master/includes/OutputTransform/DefaultOutputPipelineFactory.php#L53-L71

Maybe the ExecutePostCacheTransformHooks? Probably worth discussing with the broader group.

The "more modern" way is indeed plugging into the OutputTransform pipeline in core, which would (eventually) allow caching the mobile-transformed content as well, so that would be a performance win. Right now the only extension point is the ParserOutputPostCacheTransform hook, which is a fine way to get started, but as you mention some of this code might want to be integrated in core with a new parser option to control it, something like ParserOption::setLazyLoadTransform(true) and then the transformation code would live in a new OutputTransform\Stages\ApplyLazyLoadTransform class in core. If the mobile transformations contain to live outside core, then we'll probably need to add a way for extensions to define their own output flavors, but those hooks aren't quite defined yet.