Basic Viewer Print Widget in IE

[PaulHoeffler]

The print widget on the basic viewer produces output most of the time on Firefox and Chrome, but on IE the button does nothing and looking in the logs the following error is registered:

Error: esri.config.defaults.io.proxyUrl is not set. If making a request to a CORS enabled server, please push the domain into esri.config.defaults.io.corsEnabledServers.

I'm not using a proxy server and the print service that I'm using is on the same domain as the viewer.

Any thoughts on how to avoid the error and get the print widget working?

Thanks in advance,

Paul

[KellyHutchins]

Based on the error message it sounds like you need to setup the proxy. Details on how to do so can be found here:

Esri/resource-proxy · GitHub

[PaulHoeffler]

All services are on the same domain and Chrome and Firefox work fine without the proxy, but for some reason IE won't work without one. I can't reasonably have the proxy server installed on the web server due to institutional barriers; I'll play around with it some more, but any further thoughts on why IE is having trouble would be appreciated.

[KellyHutchins]

Which version of IE? CORs support wasn't added until IE10.

http://caniuse.com/#feat=cors

[PaulHoeffler]

It is IE 9, and unfortunately that's the version of IE that will be on most employees' machines here.

If the web server hosting the viewer is on the same domain as the ArcGIS server hosting the web map export task I didn't think that I was using CORS - I may have a misunderstanding here?

If that's the case I'll read up on it further.

[KellyHutchins]

If all the requests are to the same domain as the application then you don't have any cross domain requests and will not need a proxy.

However based on the error message you are seeing I suspect there is a cross domain request happening and it needs the proxy. In general its a good idea to setup a proxy and refer to it in your app. Then if needed it will use the proxy and if not needed it ignores it. I understand that this may not be possible in all organizations but it might be worth looking into it to see if you can get permissions to install the proxy on your web server.

[PaulHoeffler]

I recognize that there are a number of benefits to using the proxy and I'll see about the possibility of having it installed, but security on the servers is rather tight.

The part that doesn't make sense to me is that the web export task is hosted internally and is not working (just in IE), but the geocoder that is hosted on ESRI servers (cross domain from the viewer) works fine. I tried switching the viewer to the ESRI web export task and it throws the same CORS/proxyURL error.

Thanks for taking the time to look at this.

[PaulHoeffler]

I just realized that some of the layers in the map won't display in IE9 but work fine in Chrome and Firefox, I think I'll just have to advise people not to use the viewer with IE9.

Thanks again for taking the time, I know how maddening browser-specific issues are.

Best,

Paul

[KellyHutchins]

Paul,

Strange about the layers not displaying in IE9. Any errors in the developer console? Perhaps this is worth logging a call to support so they can help troubleshoot the issue.

You asked why the geocoder worked but not the print task so thought I'd provide more info. Here's an old thread by Jian Huang that discusses some of the scenarios when you need a proxy and when you don't.

In the use cases he lists the geocode is covered by 2a. You can test this by running one of the geocode samples  in IE9 while using something like Fiddler to inspect the network traffic and look for the jsonpCallback that Jian mentions.  There's a bit of info in this wikipedia article on jsonp vs cors.

[PaulHoeffler]

Thanks for the links, I'm reading them over now.

I find that with the print widget in Chrome and Firefox sometimes I get the output I expect, but often I don't get any output, and looking further I see there are CORS errors there - odd that it's sporadic, but I'll try to get the server-side CORS support and/or proxy installed on this end.

I do get a laundry list of errors in all browsers when the viewer loads, but I had been ignoring them to this point since it was functioning as expected. If you think they're relevant I'll post them, although please let me know if another thread or space would be more appropriate - I'm also looking into our organizational information for calling support.