Problem re-initialising map in Microsoft browsers

[Zev19]

mapbox-gl-js version: v0.22.1

Steps to Trigger Behavior

1. Refresh page/redirect back to map from another page. Test case on example page https://www.mapbox.com/mapbox-gl-js/examples/

Expected Behavior

Map loading normally

Actual Behavior

Map does not load, 404 error returning under F12, script not found. Seems to only occur with Internet Explorer and Microsoft Edge

[tgecho]

I can confirm the error on this specific page in Edge and IE11. I've also had a lot of sporadic issues in IE that seem to most commonly come and go on every alternate page refresh.

[tgecho]

I did a little manual bisecting and I think I've narrowed it down to something in this commit: def9cb5 (Refactor Source interface to allow/prepare for extensibility CC @anandthakker).

If I use the commit before this one, everything seems to work fine. With this commit, every other time I reload the page, the map doesn't load/update in IE11/Edge.

This commit is a bit involved, but I'll keep digging to see if I can find the precise culprit.

[tgecho]

It seems to primarily affect to vector tile and/or geojson layer changes made after initialization.

[tobinbradley]

Can confirm. Only thing to add is it looks like the map style.load event fires but the map load event never fires when the map doesn't draw. Reverting back to 0.21 fixes the problem. Edit: nope, still there in 0.21.

Really strange - no error messages, and it's literally every other page refresh. Holds true for page navigation history too. If I hit a page with a gl map, go to a different page, and keep hitting the forward/backward buttons to switch between the two, it does the same thing - only works every other time.

[hellkama]

Is there any known workaround for this issue other than using old versions of the library? This is quite critical bug for me as large portion of my users use the affected browsers.

[jd327]

Is there an ETA on this bug fix? Same problem, have users that can't use the map.

[mourner]

@anandthakker any chance you could look into this?

[anandthakker]

I definitely plan look into it (this browser tab has been open for a while now!) -- but I'm scrambling towards a deadline right now, so it might still be a few days / next week before I can dig into this.

[jd327]

@anandthakker not to get too greedy, but is there any chance this might make it into 0.25.0? 😓

[anandthakker]

@ivanakimov I think the next release is tracked by this milestone -- but if the fix doesn't make it in before that that gets shipped, perhaps it could go into a patch release (0.25.1 or something). I definitely want to resolve this ASAP... but my "day job" is in crunch time.

[jd327]

@anandthakker Ah, got ya. Makes sense. Yeah, bummer about this issue, cause it's quiet noticeable at the moment. Ok, will wait. Thank you.

[mollymerp]

@anandthakker any update here? I've added it as a release blocker to make sure we get this fixed before Edinburgh. Happy to take a look if you're swamped but I'll need to get my hands on a windows machine 😅

[anandthakker]

@mollymerp oof, I'm really sorry 😞 - I'd really hoped to get into it this week, but I've been behind and still trying to catch up.

Looks like Edinburgh is meant to go out on the 12th. I do think I'd be able to jump into this by Tues, but that's pretty close to the 🚢 date. If you're able to get a head start before then, I'd be happy to team up or take over next week.

(Btw, re: windows machine: I was going to try using Browserstack to debug, which is going to be... tons of fun. Heh.)

[mollymerp]

@anandthakker thanks for the update and no worries! I know you're busy!

I just tried to reproduce this bug on IE11 and I wasn't able to see the bug described here. Removing as a release blocker for now until we are able to reproduce and therefore debug + fix. Apologies for the delay on this one.

[jd327]

It's reproducible on Edge (and in IE11 mode on Edge) if you refresh a few times. Sometimes it loads fine, and sometimes it does not. For us, it was about 50%.

[hellkama]

Yep I don't think this should be hard to reproduce as it happens on every second page load at least on my Win 10 machine. Haven't had chance to test other systems. Language / regional settings is one possibility if it works normally on some systems?

Video of the bug happening: https://gfycat.com/IndelibleEveryAbyssiniangroundhornbill

[tgecho]

For what it's worth, my IE testing machine is a vanilla Modern.ie VM in Parallels

[jd327]

@lucaswoj I actually have customers leaving because of these Windows/IE bugs (#3040, #2942). Was so looking forward to these fixes and now they're not even in Edinburgh release...

Is there an ETA for them? Aren't they release blockers if the map is not showing?

[lucaswoj]

@ivanakimov We hear you 😞. Unfortunately we have been unable to reproduce these bugs in our in-house windows machine. Without the ability to repro the bug, there's little hope of a fix, and with little hope of a fix, it seems foolish to indefinately delay the next release. This is high on my priority list.

[jd327]

Let me know how I can help you reproduce.

I realize tracking down bugs like these is a pain in the a, but looks like there are quite a few people that are noticing this, not just us. Also, if you'd like to see the map we're using, just ping me.

For #3040 we reproduced it on:

Microsoft Edge 38.14393.0.0
Microsoft EdgeHTML 14.14393
Windows 10

For #2942, it was exactly what was reported: Chrome + Windows 7. Also applying pitch (of 20 degrees) helped avoid the issue. Edit: Windows 10, not 7, derp.

[jd327]

@anandthakker any luck on fixing this?

[hellkama]

I don't understand how this issue doesn't get any love.

25% of my (enterprise) users have IE11 or Edge. We cannot dictate the browsers that are deployed to their machines.

This should help you if you don't have Windows boxes:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

I tested with the "Microsoft Edge on Windows 10 Stable (14.14393)" and the bug is there. It should be easily reproducible with these VM images.

[jfirebaugh]

I can reproduce the issue in the "Microsoft Edge on Windows 10 Stable (14.14393)" VM that @hellkama suggested. The symptom that I saw was that when loading the debug page (npm start, then open http://localhost:9966/debug/ -- or in my case, within the VM http://10.0.2.2:9966/debug/), the first refresh results in a blank map, and then subsequent refreshes alternate between a working map and a blank map.

I added some tracing to the code, and what I saw is that in the cases where the map is not working, it's because the Web Workers simply never receive any messages that are posted to them from the main thread. I can't see any reason why they shouldn't, or why this would happen on every second refresh. I think it must be an IE bug.

@csuwildcat, is this something you can have someone on your team look at?

[csuwildcat]

If I had to guess, I would say it's probably an issue with Workers being created/accessed/cached on localhost/IP-based URLs. Many browsers have security enforcement that cause issues when using certain APIs (Web Workers, Service Worker, File, etc) with local origins.

[jfirebaugh]

@csuwildcat Here's a minimized test case. I think it demonstrates pretty conclusively that this is an IE bug. Load it up, open developer tools, and hit refresh -- you'll see that after the first load, the worker doesn't receive any messages. If you comment out the var xhr = new XMLHttpRequest(); line, it works as expected.

<script id="worker" type="worker">
    console.log('worker created', self);

    self.addEventListener('message', function(e) {
        console.log('worker received message', e.data);
    }, false);

    var xhr = new XMLHttpRequest();
</script>
<script>
    var src = document.getElementById('worker').innerText;
    var blob = new Blob([src], { type: 'text/javascript' });
    var workerURL = URL.createObjectURL(blob);
    var worker = new Worker(workerURL);
    setTimeout(function () {
        console.log('posting messages to worker');
        worker.postMessage(1);
        worker.postMessage(2);
        worker.postMessage(3);
        worker.postMessage(4);
    }, 10);
</script>

[mourner]

@jfirebaugh I'm puzzled about this comment then #3040 (comment), which says the bug did not trigger in an earlier GL JS version but started happening after @anandthakker's changes. Is this actually the case?

[jfirebaugh]

Opened an issue: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9545866/

[jfirebaugh]

@mourner Given how simple the reduced test case is, I think it's probably not related to @anandthakker's changes -- or if it's is, it's related only in that his changes changed the timing in a way that triggered the bug where it wasn't triggered before.

[anandthakker]

@mourner I have been puzzled about that as well -- there were certainly a lot of changes in #2667, but not ones that (at least on the surface) would seem to affect main-thread/worker communication like this. (If the offending change had been, say, the global worker pool one, that would be less surprising.)

In any case, for anyone watching: this is causing a compatibility bug in a project of ours whose Nov 8th ship date is about as inflexible as they come... so I definitely have to work on it very, very soon -- I'll post back here if I come up with any kind of workaround.

@jfirebaugh kudos for isolating XmlHttpRequest

[tgecho]

@csuwildcat I happens for me on an official example https://www.mapbox.com/mapbox-gl-js/examples/, so I don't think it's (only) a localhost/ip thing.

@mourner I'll try do another pass to confirm my earlier observation about that commit as soon as I can.

[jfirebaugh]

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9243268/ looks likely to be related.

[tgecho]

I just ran through those two commits again using the "Display a map" example. The bug occurs reliably on def9cb5 and not at all on 302aadd. However... from what the others have show I think @jfirebaugh is likely right that it's only the distantly triggered race condition.

[tgecho]

To add to the weird race condition smell, I found that if I modify the example to initialize the map with an empty style and setStyle immediately after the bug seems to go away.

var map = new mapboxgl.Map({
    container: 'map',
    style: {version: 8, sources: {}, layers: []},
    // style: 'mapbox://styles/mapbox/streets-v9',
    center: [-74.50, 40],
    zoom: 9
});
map.setStyle('mapbox://styles/mapbox/streets-v9');

Hope that's worth something ¯_(ツ)_/¯

[jfirebaugh]

Got a reply on the issue I filed:

Ibrahim O. commented:

Thank you for your feedback. We would like to inform you that this issue has been previously identified and the fix is currently available in the insider preview which will be also available in the public stable version in upcoming updates soon.

Best regards,
The MS Edge Team

[jd327]

will be also available in the public stable version in upcoming updates soon

@jfirebaugh Good to hear they're fixing this. Does this mean that only the new Edge versions will have the patch? (as in IE11 will still have these issues?)

[twelch]

This issue appears to be fixed by Microsoft as of Edge developer preview 15.15014, released 1-19-17, but no public release since. I tested the GL JS examples with the Windows 10 Preview VM here - https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. None of the load issue I see with the current stable release.

[jfirebaugh]

Thanks for checking @twelch! When I looked into this, I didn't see a feasible workaround, so I think we have to rely on the Edge bugfix alone to resolve the issue. I'll close here.

[strech345]

@tgecho
if i init with a empty style and set the style later, the bug comes more then as default.

[BBaysinger]

I just started encountering the behavior that some people were saying they observed. The first time I load a map on the page (single page app), there's about a 50% chance it wont render all the layers. But I used @tgecho's trick:

...I found that if I modify the example to initialize the map with an empty style and setStyle immediately after the bug seems to go away.

...and it appears to work after about 30 page refreshes, so far.

I'm using v~0.44.x, and I tested all the way back to v~0.38.0, and still had the same issue.

[Rajavelu]

To add to the weird race condition smell, I found that if I modify the example to initialize the map with an empty style and setStyle immediately after the bug seems to go away.

var map = new mapboxgl.Map({
    container: 'map',
    style: {version: 8, sources: {}, layers: []},
    // style: 'mapbox://styles/mapbox/streets-v9',
    center: [-74.50, 40],
    zoom: 9
});
map.setStyle('mapbox://styles/mapbox/streets-v9');

Hope that's worth something ¯_(ツ)_/¯

Still, Not working for me.