Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem re-initialising map in Microsoft browsers #3040

Closed
ghost opened this issue Aug 20, 2016 · 40 comments
Closed

Problem re-initialising map in Microsoft browsers #3040

ghost opened this issue Aug 20, 2016 · 40 comments

Comments

@ghost
Copy link

ghost commented Aug 20, 2016

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
Copy link

tgecho commented Sep 9, 2016

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
Copy link

tgecho commented Sep 12, 2016

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
Copy link

tgecho commented Sep 12, 2016

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

@tobinbradley
Copy link
Contributor

tobinbradley commented Sep 20, 2016

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
Copy link

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
Copy link

jd327 commented Sep 27, 2016

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

@mourner
Copy link
Member

mourner commented Sep 27, 2016

@anandthakker any chance you could look into this?

@anandthakker
Copy link
Contributor

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
Copy link

jd327 commented Sep 27, 2016

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

@anandthakker
Copy link
Contributor

@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
Copy link

jd327 commented Sep 27, 2016

@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 mollymerp added this to the Edinburgh milestone Oct 6, 2016
@mollymerp
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link

jd327 commented Oct 8, 2016

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
Copy link

hellkama commented Oct 8, 2016

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
Copy link

tgecho commented Oct 8, 2016

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

@lucaswoj lucaswoj removed this from the Edinburgh milestone Oct 12, 2016
@jd327
Copy link

jd327 commented Oct 13, 2016

@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
Copy link
Contributor

@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
Copy link

jd327 commented Oct 13, 2016

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
Copy link

jd327 commented Oct 17, 2016

@anandthakker any luck on fixing this?

@hellkama
Copy link

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
Copy link
Contributor

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?

jfirebaugh added a commit that referenced this issue Oct 26, 2016
@csuwildcat
Copy link

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
Copy link
Contributor

@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
Copy link
Member

mourner commented Oct 26, 2016

@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
Copy link
Contributor

@jfirebaugh
Copy link
Contributor

@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
Copy link
Contributor

@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
Copy link

tgecho commented Oct 26, 2016

@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
Copy link
Contributor

@tgecho
Copy link

tgecho commented Oct 27, 2016

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
Copy link

tgecho commented Oct 27, 2016

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
Copy link
Contributor

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
Copy link

jd327 commented Nov 1, 2016

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
Copy link
Contributor

twelch commented Mar 21, 2017

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
Copy link
Contributor

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
Copy link

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

@BBaysinger
Copy link

BBaysinger commented Apr 27, 2018

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests