Original User: cwright25
@Jeff - Can you be a little more specific about your workaround? It may be better than what I am about to use. I'm using background maps from ArcOnline so I have various LODs to zoom to. If I try "centerAt()" then "setLevel()" in the same function call, it causes a race condition and the second function, "setLevel()" wins. I tried calling "setLevel()" in the "onPanEnd" event, but it does not help when staying at the same zoom level. What I've found works is calling "setLevel(1)" to zoom almost all the way out, and then in the "onExtentChange" event calling "centerAndZoom()". Obviously this involves some bad programming practices, such as using a global variable to store the point to while waiting for the "OnExtentChange" to fire. Ultimately I think this is a better solution than what I was about to do, which is pop up an alert for IE users stating "To see labels, switch to Chrome, Firefox, or Safari". 🙂 Also, if I didn't state it before, I originally had this issue with the "setExtent()" function, and moved to "centerAndZoom()" only after "setExtent()" failed with the same issue. I'm guessing these 2 function calls share the same dependency code.
@swingley - I have done so (Incident 1005617), and was informed that this is Bug NIM054233: Zooming in twice using map.centerAndZoom to level 14 produces odd results in Internet Explorer. So two comments:
1. As Jeff stated, this bug has been around a while - it was originally reported nearly 2 years ago, Feb. 17, 2010.
2. The bug description is not really accurate, as Level 14 is not the only one affected, and I wouldn't simply call it "odd results", as it consistantly causes an error to be thrown when panning after the second zoom, and the graphics consistantly fail to draw.
Would it make any difference at this point if I also placed a request to escalate this bug, or are you guys on it? Thanks for all you do.