Preliminary inestigation: I tested this at Czech Wikipedia, and I can confirm the behaviour, with one difference: I see no placeholder at all:

Further checks show that both lines actually represent placeholder with width: 0 set on them. Fixing that in the developer tools shows two placeholders:

The good question is why this happens, but this is definitely important for us to work on.

For some reason,this.model.getAttribute( 'width' ) seems to be evaluating to 0. I do not understand why though (or when that changed). I asked @Sgs to have a look.

I updated

In T348362#9290874, @Urbanecm_WMF wrote:

For some reason,this.model.getAttribute( 'width' ) seems to be evaluating to 0. I do not understand why though (or when that changed). I asked @Sgs to have a look.

That's the issue making the placeholder narrow; the height is also evaluating to 0 since its derived from the width in AddImageArticleTarget#275 but the fallback is preventing the placeholder height to shrink. I have no clue yet what has changed in VE/GE/OOUI to make this happen. Maybe some markup has changed making the this.surface.getView().$documentNode element no longer have a computed width? Or we're running into some initialization race I cannot see yet. Insight from Editing-team would be appreciated to identify what changed to break the placeholder logic. cc @Esanders @matmarex

Regarding the additional visual element inserted I think it relates to the fact we're creating two instances of RecommendedImageToolbarDialog and that calls insertImagePlaceholder twice resulting in two (broken) placeholders. The issue seems to be present in all structured tasks as the double instantiation comes from the ve.loadModules hook handler firing more than once. Did something change in MobileFrontend to fire more than one ve.loadModules event? cc @Jdlrobson

Change 973834 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] Section images: avoid inserting broken and duplicated placeholder

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

In T348362#9327267, @Sgs wrote:

(…) I have no clue yet what has changed in VE/GE/OOUI to make this happen. Maybe some markup has changed making the this.surface.getView().$documentNode element no longer have a computed width? Or we're running into some initialization race I cannot see yet. Insight from Editing-team would be appreciated to identify what changed to break the placeholder logic. cc @Esanders @matmarex

I've placed a breakpoint on this line: https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/6344ef5d492ddcf33b5ca62e796d28f5bfa9c6b2/modules/ext.growthExperiments.StructuredTask/addimage/AddImageArticleTarget.js#269 and found that it has no width because it's not displayed at all at this point, the whole overlay is hidden with display: none.

It definitely seems like something has changed about the order of initialization. Changes from T239676 may be the culprit (I didn't try to check, but it's the only thing I'm aware of).

But, taking a step back, it seems to me that measuring the width of the screen to set the size of the placeholder isn't that great. Wouldn't it result in incorrect rendering if the user rotates their phone between portrait and landscape after opening the editor? I would suggest using the default thumbnail size, just like on desktop, and then setting max-width: 100% in CSS, just like MobileFrontend does for real images.

(by the way, I'm on the MediaWiki Platform team now :) )

(…) The issue seems to be present in all structured tasks as the double instantiation comes from the ve.loadModules hook handler firing more than once. (…)

FWIW, I wasn't able to reproduce that, and I didn't see the doubled-up placeholders.

In T348362#9342685, @matmarex wrote:

I've placed a breakpoint on this line: https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/6344ef5d492ddcf33b5ca62e796d28f5bfa9c6b2/modules/ext.growthExperiments.StructuredTask/addimage/AddImageArticleTarget.js#269 and found that it has no width because it's not displayed at all at this point, the whole overlay is hidden with display: none.

It definitely seems like something has changed about the order of initialization. Changes from T239676 may be the culprit (I didn't try to check, but it's the only thing I'm aware of).

Reverting the change makes the placeholder get back its width so there's definitely something with it.

But, taking a step back, it seems to me that measuring the width of the screen to set the size of the placeholder isn't that great. Wouldn't it result in incorrect rendering if the user rotates their phone between portrait and landscape after opening the editor? I would suggest using the default thumbnail size, just like on desktop, and then setting max-width: 100% in CSS, just like MobileFrontend does for real images.

That's true, the image is not resized neither with js or css if there's an orientation change, however it's right aligned to the text when the width reaches the tablet min-width breakpoint. On desktop we use VE's thumbLimits and the user preference, I'm not sure why on mobile we capped the width to 500px. It seems pretty random to me but I'm leaving it in place just in case.

(by the way, I'm on the MediaWiki Platform team now :) )

Ops, thanks for taking the time to reply here. Good luck in your new team:)

(…) The issue seems to be present in all structured tasks as the double instantiation comes from the ve.loadModules hook handler firing more than once. (…)

FWIW, I wasn't able to reproduce that, and I didn't see the doubled-up placeholders.

I'm also unable to reproduce it in production wikis but it seems consistent in the development setup. @Urbanecm_WMF @Etonkovidova are your screenshots coming from production wikis or local setup?

In T348362#9349448, @Sgs wrote:

In T348362#9342685, @matmarex wrote:

FWIW, I wasn't able to reproduce that, and I didn't see the doubled-up placeholders.

I'm also unable to reproduce it in production wikis but it seems consistent in the development setup. @Urbanecm_WMF @Etonkovidova are your screenshots coming from production wikis or local setup?

Re-tested in cswiki wmf.5 (and eswiki) - I see it consistently:

	after clicking on Yes to add the image:

The initial screenshots in the task description came from the production.

I think the changes from T334263 could explain the miss-behavior. If I revert 931501 the placeholder is inserted only once.

It seems the overlayManager.add callback in setupEditor() is being called twice; one coming from a OverlayManager docReady handler and the second from OOUI router hashchange listener. That leads to double call of mw.libs.ve.targetLoader.loadModules firing repeated ve.loadModules events and causing double registration of GrowthExperiments' plugins on mobile.

If I defer the router.navigate call eg: util.docReady( function () { router.navigate( fragment ); } ); the overlay callback is only triggered once because the path has not yet been set when OverlayManager docReady handler kicks in. But I'm not sure if there are unintended consequences of doing that.

@DLynch @Jdlrobson does this make any sense? I've submitted a tentative patch but maybe you can provide guidance on a preferred solution? Maybe the OverlayManager docReady handler is not needed anymore?

Change 978117 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/MobileFrontend@master] mobile.init: avoid hash changes before document loads

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

Change 978117 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] mobile.init: avoid hash changes before document loads

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

The fix works in beta.

The issue is still present in wmf.9 since the fix for T352208: [wmf.29] [mobile] Section level image placeholder has no width will be deployed for wmf.10.