Embedded map refresh shows whole world in Chrome

[ItsLifeJim]

Hi,
We're using an embedded map in an IFrame. Whenever we refresh the page in Chrome (latest vanilla GA) we get the whole world rather than the normal area we get. This works fine in Firefox (and reports from others that IE is good too). There is chat about this in: https://forum.openstreetmap.org/viewtopic.php?pid=774298#p774298

I've been told this wasn't a problem in earlier versions of Chome, so guessing this might be related to recent cross-origin or security changes they've made.

You can see an example of it at https://www.fishersgreensc.org.uk/ (bottom LHS). The iframe it's using is:
<iframe src="https://www.openstreetmap.org/export/embed.html?bbox=-0.014516115188598635%2C51.721292696505174%2C-0.002521276473999024%2C51.72513413988513&amp;layer=mapnik" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="200" height="300" style="border: 1px solid black;"></iframe>

I've tried relaxing various iframe security features, but with no luck.

Please let me know if you need any more information or an recommend any changes to the frame.

Kind regards,
Bill

[mmd-osm]

I can only reproduce this in Chrome 80 when following these steps:

1. Go to https://www.fishersgreensc.org.uk/
2. Open openstreetmap.org in a second tab
3. Reload https://www.fishersgreensc.org.uk/ in the first tab.

When skipping step 2, I don't see the effect you're describing.

Can you confirm if this is what you're doing?

[tomhughes]

Investigating... Oddly that location is just a few miles from me ;-)

[tomhughes]

I can't reproduce it in Firefox certainly. It sounds like it is preferring the _osm_location cookie over the location in the URL for some reason - does flushing cookies fix it by any chance?

[tomhughes]

Just reloading seems to fix it in fact and after that reloading osm.org doesn't seem to affect it any more?

[tomhughes]

Don't think it's cookie related - the code is very simple and just defaults to the whole world if there is no bbox in the parameters so for whatever reason it seems Chrome isn't sending the parameter.

[mmd-osm]

Hmm, could this be somehow timing related, i.e. setting the bbox is executed a bit too late?

[tomhughes]

That's my suspicion. I'm not sure it's related to loading the main site at all, it just seems to be totally random whether it happens. I've even had it happen on the first load in a new Chrome.

I think that window.onload is sometimes running before window.location.search is available somehow.

[tomhughes]

I've managed to reproduce it with some debugging in the javascript and that is definitely getting the argument going through the map.fitBounds path so my new guess is that it's a race condition inside leaflet where calling that too quickly after creating the map can cause it to fail.

[ItsLifeJim]

I can see you guys are making progress. Please let me know if there's anything I can help with regards testing.

PS. I can reproduce the problem on Chrome 80 as follows:

1. Totally clear Chrome cache and restart.
2. Load https://www.fishersgreensc.org.uk. This will show the correct map tiles.
3. Refresh chrome and you'll see the world tiles.
4. You can also restart chrome, load the above page and you'll see the world tiles again.

[ItsLifeJim]

Hi,
A forum member has found that using Object or Emded frames seems to work around the problem. It does for our site, so I've switched to Object there for now:

https://forum.openstreetmap.org/viewtopic.php?pid=777331#p777331

Regards,
Bill

[Archibald2]

I find maps are loading correctly in Chrome when I use the Leaflet JavaScript Library but not when I use an iframe.

Because my websites are responsive (Flexbox CSS), I am only using the iframe's 'src' attribute with URL obtained via OpenStreetMap's 'Share' button. However I do not think this is affecting the issue.

I too think the issue may be caused by a timing or "race condition". This has led me to trying this code which I find shows the correct map:

<iframe id="map1" class="Box_Map" src=""></iframe>
<script>document.getElementById("map1").src="https://www.openstreetmap.org/export/embed.html?bbox=0.09304046630859376%2C52.14381308981805%2C0.6663894653320314%2C52.32925493016711&amp;layer=mapnik"</script>

Note: my class "Box_Map" styles the iframe instead of attributes from the 'Share' button embed code.

If this is a timing issue, I cannot guarantee this solution will work on a very fast PC. An alternative approach would be to put the script in another file and embed it using the HTML 'defer' attribute.

It is evident that the query string portion of the URL (bbox=......) is saying what area of the world the map should cover. So if the URL (with bbox query string) is obtained with a map displayed in a large browser window, at least the same area of the world will be displayed when displayed within a relatively small iframe. To do this, I expect JavaScript code within the web page from OpenStreetMap is getting the iframe's dimensions (in pixels) using window.clientWidth and window.clientHeight. This is where I guess there is a timing bug in Chrome.

[Thesephi]

Hi, I got this issue, too, and adding the loading="lazy" attribute to the iframe element works for me, so:

<iframe loading="lazy" src="..."></iframe>

Not sure if it helps in all cases, just wanted to share 1 potential way for those who are facing the same issue.

[Pastafarian24]

Having the same issue in Firefox. Sometimes it will set the zoom level to 0 randomly. Changing the iframe to an object seemes to have fixed it.

Edit: Didn't fix it. Still the same issue.

[Eweiss84]

<iframe loading="lazy" src="..."></iframe>

that works for me 2... thanks to Thesephi

[Lett1]

Can confirm that this still happens on Firefox 104, even when using an object element.

[Buntbart]

I am only Typo3 user without admin rights and can only edit the src:" "-field of iFrames. I have no access to other parameters.
Is there any hope that sometime on the openstreetmap.org side a solution will be implemented?
Most people use Chrome and very few empty their browser cache. The anger about this bug falls on OSM, not Chrome.

[tomhughes]

Sure, as soon somebody can explain what is happening and how to fix it we'll be happy to do so.

I know a "fix" is included in these comments but there is no explanation as to what is going wrong or why that fixes it so it's impossible to determine if it is the correct solution or if it may break other things.

[Buntbart]

I am not a developer, but I think after three years it would be time for some experiments to get closer to an explanation and a solution.
Alternatively, a wiki page could be created for admins to collect workarounds. In the worst case the export function of osm.org should disappear imho.

[HolgerJeromin]

I am not a developer, but I think after three years it would be time for some experiments to get closer to an explanation and a solution.

We have 500 open issues and only volunteer people working on this code base.
"it would be time for" does not work well for unpaid developers.

[tomhughes]

Oddly I can't actually reproduce this in chromium 105 though I did apparently manage to reproduce it when this was originally opened.

[Buntbart]

I apologize, I didn't mean to attack anybody. I also map unpaid and I could do more if I had the time. And I have now also seen that your oldest issues here are older than 10 years, wow.

I have Chromium 106 and 107 here on Linux, and Chrome 107 and Edge 107 on Windows, all showing Zoom 0 after reloading the page. Only "reload frame" makes the correct zoom level. I don't have the problem with Firefox. Unfortunately, not many people use Firefox anymore.

[ItsLifeJim]

I think the OSM folks have enough on their plates and there have been a couple of workarounds provided - closing.