Page MenuHomePhabricator

Frameless mapframe shows the wrong thumbnail in edit source preview
Closed, ResolvedPublic

Description

Mapframe with the frameless attribute is showing the wrong thumbnail when previewing (using source editor).
Examples from User:Evad37/Sandbox 11 on enwiki:

==Frameless==
<mapframe zoom="10" frameless="1" align="center" longitude="-122.399112" latitude="37.785407" height="200" width="270">{"type":"Feature","geometry":{"coordinates":[-122.399112,37.785407],"type":"Point"},"properties":{"marker-color":"#5E74F3","title":"Benu","marker-symbol":"restaurant"}}</mapframe>

==Framed==
<mapframe zoom="10" align="center" longitude="-122.399112" latitude="37.785407" height="200" width="270">{"type":"Feature","geometry":{"coordinates":[-122.399112,37.785407],"type":"Point"},"properties":{"marker-color":"#5E74F3","title":"Benu","marker-symbol":"restaurant"}}</mapframe>

results in


instead of the frameless map having the same thumbnail as the framed map.

Event Timeline

Evad37 created this task.Mar 28 2020, 12:10 AM
Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptMar 28 2020, 12:10 AM
TheDJ triaged this task as Unbreak Now! priority.Mar 30 2020, 6:55 PM
Pikne added a subscriber: Pikne.Mar 30 2020, 8:12 PM

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).

TheDJ added a subscriber: TheDJ.Mar 30 2020, 11:17 PM

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' ?

Pikne added a comment.EditedMar 31 2020, 1:03 PM

what do you mean 'collapsed' ?

Like this (all in page preview).

During page load:


After page load:

After window resize:

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.

TheDJ added a comment.Mar 31 2020, 2:43 PM

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 ?

Pikne added a comment.Mar 31 2020, 3:03 PM

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).

TheDJ added a comment.EditedMar 31 2020, 8:11 PM

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.

TheDJ added a comment.Mar 31 2020, 9:35 PM

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.

TheDJ claimed this task.Mar 31 2020, 9:35 PM

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

Jdforrester-WMF closed this task as Resolved.Apr 2 2020, 8:06 PM