Interestingly resizing a browser window gets JSON overlay object loaded and map centered to it for frameless dynamic map. Similarly, since recently I observe that when using auto-positioning (omit frame coords/zoom), then JSON overlay and some tiles don't appear until after window resize for both frameless and framed dynamic map (at least in some browsers).

I’m aware of an issue in the initialization phase that causes similar problems, though I’ve rarely seen it at first render. It mostly occurs when previewing and when loading the fullscreen dialog.

But this is likely no new issue. Consider that until recently, autozoom was broken completely, so fixing that just made this bug surface again (autozoom is a modification in the init phase of maps).

Actually I observe the same behaviour (window resize makes JSON overlay/all tiles appear, as in Evad's frameless map example) also when not using autozoom, particularly when map has new/updated (uncached) JSON. There apparently are some difference between browsers (or browser versions) for this behaviour, but for me, until very recently this didn't happen and content for dynamic maps generally loaded well, including when previewing and in Commons/Wikidata that don't use static frames. I don't know if related, but it's also new for me that these improperly initialized frames are collapsed during page load (related to switching to <img>?).

what do you mean 'collapsed' ?

In T248722#6014466, @TheDJ wrote:

what do you mean 'collapsed' ?

Like this (all in page preview).

During page load:

Using:
<mapframe align="right" height="200" text="Kaart" width="220" zoom="15">[{"properties":{"description":"","stroke-width":3,"stroke":"#C70039"},"service":"geoline","type":"ExternalData","ids":"Q31273609"}]</mapframe>

I get this only in (older) Firefox though, not in Chrome for example. Week ago or so I didn't get this collapsing behaviour and JSON overlay not loading without window resize in the same browser.

Well that would explain the behavior, but it's strange... Maybe Firefox cannot calculate the dimensions correctly when the <a><img/></a> is not yet loaded ?
Hmm, maybe especially with the CSS that we use now...
Which version of Firefox is this ?

In T248722#6014843, @TheDJ wrote:

Which version of Firefox is this ?

It's 52. As other browsers, though to lesser degree, are also affected by similar problem that is described in task description, then I'd think it's not only about my go-to browser being too old. :)

Similarly, on betawiki frames are collapsed after page load too (e.g. here, before they were just blank due to referring to non-existent maps-beta.wmflabs.org).

When the image is missing, then this is expected. Per the spec for replacement content (img elements being replaced by actual images)... the image can never be downloaded. There is also no alt="" text, which means no replacement text, dimensions 0x0.. Perhaps that's also why you will see this fail in preview. As previews do not have staticmap images as fallback, that might also render to 0x0..

Hmm, in that case, i'll have to move the CSS to set those style params a little bit higher in the loading order, so that leaflet doesn't have to fallback to the intrinsic size of images.

Sorry that I missed this. Safari does not comply with the spec (doesn't make the image 0x0 if it permanently cannot be loaded) and I didn't notice when implementing <img> support.

Change 585041 had a related patch set uploaded (by Jforrester; owner: TheDJ):
[mediawiki/extensions/Kartographer@master] Follow-up 9c8e1dc: Force dimensions when we have no src for img element

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

Change 585041 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] Follow-up 9c8e1dc: Force dimensions when we have no src for img element

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