nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Zoom hangs when going from high level to low

DanielGarcia

When I execute centerAndZoom method or other method that change zoom level from high level like 19 to low level like 2, application hangs taking a lot of memory (up to 1,5 Gb).

You can test it with this simple jsfiddle... https://jsfiddle.net/dgarcrom/1dbvjqyx/

This not happend with IE, it's happend with Chrome 46.0.2490.71.

Any ideas??

Thank you.

Find more posts tagged with

Accepted answers

All comments

BhavinSanghani

Hi Everyone,

I tested Daniel's example with JS API 3.13 and it is working with Chrome 47.0.2526.80 m (see attached). It seems no memory leak issue with Chrome 47 that was seen with Chrome 46. Do you guys see any issue with lesser than 3.15 api on this topic and application might stop working?

I am trying to figure out whether I should upgrade JS API from 3.13 to 3.15 in our product. Since we have already released our product, I am trying to avoid to 3.15 upgrade if there are no real issues reproducible anymore with the latest Chrome release.

Any thoughts?

CenterAndZoom_Chrome47.zip

clip1.png

DanielGarcia

Good News!!!

3.15 API version solve this issue. You can test it in this jsfiddle

ESRI JS API 3.15 - JSFiddle

Thank's to all.

Daniel

BledarBirbo1

according to Murphy's laws, things would go wrong only when they affect a large number of users.

hope that answers you Win 8 question.

NickJohnson2

I was investigating this issue, and just to test, I installed the latest Chrome beta. The bug went away, so it looks like whatever is causing it has been fixed, and will eventually make it into the next Chrome release.

BhavinSanghani

Ok, got it!

Any idea about regarding map cut-off? I don't see anything wrong in your code, but still it cuts-off. Do you think that one is also a bug?

<!-- on(dom.byId("zoomInBtn"), "click", function(){

map.centerAndZoom([-122.45, 37.75], 19);

});

-->

DanielGarcia

No,

In this jsfiddle (Bug Navigation Mode - JSFiddle ) use mouse wheel to do zoom in and zoom out and look at the texts. They have been accumulated in the map.

BhavinSanghani

Hi Daniel,

When you say tiles are not drawn correctly, did you mean the map is cut-off on borders when loaded first time?

If I comment out following code and try to load the map then the map displayed properly without cut-offs on borders. Is this a different bug?

<!-- on(dom.byId("zoomInBtn"), "click", function(){

map.centerAndZoom([-122.45, 37.75], 19);

});

-->

DanielGarcia

Thank you Ken, but in this case this only happends when you set zoomDuration and zoomRate to 0.

Regards

kenbuja

There seems to be a couple of bugs relating to initializing the map with a basemap that has a reference layer.

Bug in Basemap Gallery dijit

DanielGarcia

As I said recently, If you put these lines into your application you can avoid this behavior...

esriConfig.defaults.map.zoomDuration = 0;
esriConfig.defaults.map.zoomRate = 0;

But I have found another ralated bug.

If you have a ArcGISTiledMapServiceLayer on top of a base map layer... this tile layer dont draw correctly. You can check this behaviour in this jsfiddle

Bug Navigation Mode - JSFiddle

In order to solve this, you should set mapNavigation to "classic"

map = new Map("map", {
  basemap : "gray",
  center : [-122.45, 37.75], // longitude, latitude
  zoom : 1, 
  navigationMode: "classic"
});

Regards

MichaelSnook

The was the trick for us...after a lot of messing around with the navigation mode items this was the workaround. Thanks Christopher! Who needs animation?

ChrisSmith7

Hah!

thejuskambi

because Win8 itself is bug

ChrisSmith7

Just a heads-up, here's some info on tests I ran using version 46.0.2490.71 (64-bit)...

OSX 10.9.5 - memory leak; crash

Win 7 - memory leak; crash

Win 8 - no crash!

I wonder why Win 8 is special...

Anonymous User

A bug has been created for this issue in ESRI Inc: Bug: BUG-000091559.
Actually this effects our API with versions all the way back to 3.10. Likely it is an issue specifically with Chrome 46.

DanielGarcia

I think you should hurry up to launch 3.15 version, because many people use this api with chrome browser.

At this moment, based in Christopher answer, I put this piece of code into my application

require(["dojo/ready", "esri/config", "dojo/has", "dojo/sniff"], function (ready, esriConfig, has, sniff) {
  ready(80, function () {
       if (has("chrome")>45) {
            esriConfig.defaults.map.zoomDuration = 0;
            esriConfig.defaults.map.zoomRate = 0;
       }
  });
});

Thanks to all

Daniel

EDIT: Chrome version > 45

YannCabon

Hi Bhavin,

For my estimate, issue affects all API versions > 2.6

This issue is due to Chrome not properly handling large scaled images.

Issue 437904 - chromium - Applying opacity to element with big scale transform freezes the page - An open-source proj…

I'm working on working around that issue internally for 3.15.

ChristopherTotty

I know you said your function is unique to your app, but could you give some more detail on how this might be accomplished? I'm not sure how one would go about throttling the zoom using a function.

NathanaelVaughan

I have experienced the issue in separate applications running API v. 3.5 and 3.12. Based upon this, I would expect the issue to be present in all releases of the API >v 3.5 (if not all).

I wrote a zoomThrottle function to limit the amount of zooming that could be generated in a single action - I set the zoom scale threshold at 100x and everything is working appropriately. I did not experiment extensively to see how much I could "push" the threshold prior to failure, although the zoom appears to be close to breaking at my current threshold (it pauses just long enough to make me think it has failed and then completes).

The function is fairly unique to my setup, otherwise I would share it. If you are concerned about the speed of an official fix, I suggest adopting a similar approach.

BhavinSanghani

I think, due to some permission issue you are not able to see the bug.

ChristopherTotty

Hi Bhavin!

Sorry, no I am not an ESRI employee, just a concerned citizen.

I believe the zoom issue is occurring somewhere inside the dojo/_base/fx module included in the ESRI init.js file.

I am not able to view the bug you submitted, for some reason. I have not filed a bug with Google/Chrome or ESRI, but it looks like we now have an ESRI employee on the case!

BhavinSanghani

Hi Yann,

Can you please share some more details about the issue and your knowledge related to this one? In which version of the API this issue has been reported? It would be great to understand other issues that Chrome introduced in past from architectural point of view?

The reason I am asking, we are approaching product release and past code complete. So, I wanted to make sure the workaround rolls out to the no. of customers with exact information. No wonder if customers consider this workaround as our product bug.

YannCabon

Hi,

The issue is logged in the API. I'm looking into it.

Unfortunately, it's not the first time Chrome introduces those problems.

MarcGraham2_2-1724621649326.png

BhavinSanghani

I experienced the similar issue yesterday that Daniel reported here. I thought it could be due to Chrome bug in 46.0.2490.71 (which I still believe). So, I submitted the bug https://code.google.com/p/chromium/issues/detail?id=545158 and it looked related to out of memory. I initially thought it's related to CORS because when I see network traffic in Chrome then request status of exportMap call remains 'pending' (see attached) and after few seconds Chrome tab is crashed.

Most surprising thing to me is - the code was working for me last Friday. But stopped working Monday morning. I suspect Chrome update would have been made silently on my machine.

Christopher - do you have more details on the issue? e.g. dojo module bug, chrome bug or something else. I am not sure you work with ESRI. If you have not submitted bug with ESRI then I can submit the bug. I am concerned on this workaround because it was working before and stopped working mostly due to chrome update. Also, it works with Chrome on Windows 2008 Server R2 standard edition. It did not work for me on Chrome on Windows 7.

ExportMap.JPG

Afbeelding 130.jpg

ChristopherTotty

Alright! I'm back and this time with a real workaround!

I have traced the problem down to the dojo module that handles the animation for the zoom. Why not just skip that? Esri provides configurable values for zoomDuration and zoomRate that are handed to the animation function. If we set both of these to 0, then the animation is skipped and no memory leak occurs.

See updated fiddle: ESRI JS API 3.13 - JSFiddle

See Esri help topic about the animation properties: Customize zoom animation | ArcGIS API for JavaScript

NathanaelVaughan

No dice for my applications. I have a version using an older version of the api and another using 3.12 (also not current) and get the same "seizing" behavior on both.

Clearly it works in the jsFiddle though.

Since it appears to be associated with "rapid" zooms, I'll probably write an intermediate function to zoom incrementally based upon some trial-and-error sensitivity testing.

Anyone have a better idea?

ChristopherTotty

I am seeing the issue locally running a site from IIS and on our production site (also IIS on a Windows Server box).

Anonymous User

Can you confirm Chrome is crashing only when using the code within JSFiddle or Sandbox or does it crash as well when using "local" code? In the tests I did it crashes only when using JSFiddle/Sandbox.

ChristopherTotty

I just tried using navigationMode: 'classic', and it works!

What is strange is, it doesn't work on its own. I happened to have a line of code placed just before the original poster's call to zoom in order to go to the debugger in Chrome Dev Tools. Without dev tools open, this line should do nothing. Without navigationMode set it does do nothing, but with navigationMode set it allows the zoom to complete.

I have no information on the actual cause other than that, but I am going to place some debugger; calls before the locations in our code where we zoom and see what happens!

Edit: I have updated the fiddle to check for Chrome 46 Win32 before running the debugger; line, just in case a supported web browser handles calls to debugger; without the browser's dev tools open.

See updated fiddle: ESRI JS API 3.13 - JSFiddle

Edit 2: Sorry for the false hope, but after multiple attempts the issue does persist. It does appear that navigationMode 'classic' did help, but debugger; or no, I am still seeing crashes.

ChristopherTotty

Yes, it is a serious problem. I was hoping there would be a solution posted here overnight, but now I guess I know what I will be working on this morning.

DanielGarcia

I was playing with some of these properties but it doesn't work.

navigationMode: 'classic',

optimizePanAnimation: true,

displayGraphicsOnPan: false,

I think this is a very serious problem, because chrome takes all memory available and hangs the computer.

All ESRI Javascript users are potencial victims.

ChristopherTotty

We are also experiencing this issue. Chrome 32-bit very quickly runs up its ~3.8GB of memory and then crashes with an "Aw, Snap!"

ChrisSmith7

Interestingly, if I attach a debugger and step through it slowly, it ends up working ok.

ChrisSmith7

Seems like a memory leak on Chrome. I tried a few different API versions to see if that helped... no such luck. Very quickly, we go from low memory usage to ~ 4 gbs in about 10 seconds (then, it crashes for me - "aw, snap"):

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.