Web app not working on chrome

JeffreyWitkamp · ‎03-24-2021

We have a portal set up for our company with a custom themed web app. Last week one of the employees complained that he could not access any feature popups on the webapp.

This week the same happened to me. I cannot use the coordinate widget, no popups are loading, and I cannot use measurement tools. Seems like all onclick content broke for Google Chrome.

Clearing cache, changing users or restarting the server doesn't do anything. There are no strange error logs.

All of this content is also working just fine on Firefox and Microsoft Edge. Really seems to be a sudden Chrome thing but I dont know how to fix it.

Also found this post from about 2 weeks ago detailing the same issue: https://community.esri.com/t5/arcgis-web-appbuilder-questions/custom-web-app-not-working-in-chrome/t...

RobertScheitlin__GISP · ‎03-30-2021

The fix is pretty simple, no need to redeploy with the latest version of WAB.

just open your WAB apps env.js and change the

var apiVersion = '3.xx';
to
var apiVersion = '3.35';
AND
apiUrl = 'https://js.arcgis.com/3.xx';
to
apiUrl = 'https://js.arcgis.com/3.35';

Clear Your browsers cache and reload apps page.

DamonNelton · ‎03-30-2021

We don't use the developer WAB just the out of the box templates in portal. If what you said still applies then I'm going to need a real step by step for dummies on how to do the above. Thanks

Brian_Wilson · ‎03-30-2021

DANGER ZONE, CAVEAT EMPTOR.

The env.js file for Portal (10.7.1 Windows version anyway) is hidden in C:/ArcGIS/Portal/apps/webappviewer and changing it will affect all apps built in Portal so I am too chicken to try that. I am going to experiment in WAB Developer Edition first to see what it does and steel my nerves.

We have just the one production server for all internal and external access because hardworking taxpayers won't let us have another for testing. (YAY restrictive licenses YAY)

If it's an option for you please try it and give me tidings of great success.

So Damon-- the steps would be,

0. Open a connection to the machine running your copy of Portal. I use a shell but do whatever makes you comfortable!

1. MAKE A BACKUP COPY first then open this file in an editor, C:/ArcGIS/Portal/apps/webappviewer/env.js

2. Search for the line var apiVersion = "3.xx" and change the digits to read 3.35. (On mine it was "3.28" and I found it on line 105.)

3. On my version that appears to be the only change. The comments from Robert say there is another line, apiUrl with the version embedded in it. On mine I found this at line 124 instead,

apiUrl = 'https://js.arcgis.com/' + apiVersion;

so I did not have to change it. There are several more variations below line 124 but they all use the variable as any good programmer would.

4. Save the file

5. Clear the cache and reload the app in your browser. Test

6. If it's now all broken, change the lines back to what they were. (I TOLD you to make a BACKUP). Tell Robert he was wrong.

7. If it works, give me (and well, Robert too) kudos. 🙂

Brian_Wilson · ‎03-30-2021

I changed apiVersion from 3.28 to 3.35 in C:/Program Files/Portal/apps/webappviewer/env.js

I am running 10.7.1 on Windows.

The fix does not work in this case because it ignores the apiVersion change and continues to load the jsapi code from the Portal server, not js.arcgis.com

Looks like it's using this: apiUrl = portalUrl + 'jsapi/jsapi/';

If you change this line to apiUrl = 'https://js.arcgis.com/' + apiVersion; then it will work.

This change means it will be pulling the jsapi code from Esri server instead of your own Portal server. If you are okay with this then, give it a go. It is working here. Please feel free to try it.

Zoom in until taxlots show, then click.

Clatsop County webmaps

DamonNelton · ‎03-31-2021

I tried the and found the same thing this morning. Even restarted the entire system and still no changes. Below is what our code looks like if it helps.

I have not tried your second suggestion "If you change this line to apiUrl = 'https://js.arcgis.com/' + apiVersion; then it will work. " ---- I'm still trying to wrap my head around what this change actually means. It may work but I don't fully understand what I'm changing and if that change has any risk to the way our organization to be set up??

Dan · ‎03-31-2021

It points to a newer Javascript API. The more recent API updates are for bug fixes as ESRI plans to retire their 3x API 05/01/2023. We all need to plan now for moving to 4x of the Javascript API.

https://developers.arcgis.com/javascript/3/

https://support.esri.com/en/Products/Developers/web-apis/arcgis-api-for-javascript/4-7#product-suppo...

Brian_Wilson · ‎03-31-2021

Actually what I did was insert the line after line 141 in your screenshot. I am still testing here, everything works so far. Changing the version number only does nothing at all because it's line 139 that's firing, generating a URL that looks like "https://YOURSERVER/jsapi/jsapi". So unless you overwrite code on your server nothing changes. When you change it to generate the URL "https://js.arcgis.com/3.35" instead, then (after you clear the cache and reload the page) it will start loading the JavaScript API from Esri's server instead of your own.

Test 1, hit this URL https://js.arcgis.com/3.35 and you should get init.js appearing in your browser. If not then don't change your code.

Test 2, insert the line after line 141, flush cache, reload, if you get errors. remove line.

Tests 3....n, test everything on your web maps that are built using Portal. You are now running a totally different Javascript library. We only use 2 or 3 non-standard widgets and everything so far seems to work fine.

The good news is that it's really easy to revert the change if things go off kilter.

I looked at my installation of WAB, Developer Edition (version 2.19) last night and it's already running API 3.35. It's not that hard to set up for testing only, so for example, I threw together an app with just the PopupPanel widget in it, tested it, confirmed it worked, did the hack to make it load JSAPI version 3.28, saw that it broke it. That way I was reasonably confident the fix would work for the PopupPanel.

Also it means the apps built with WABDE will all just work, the Chrome bug only affects the ones that I did not build. 😉 Cool! I use WABDE, the other GIS person here uses WAB in Portal.

When I was trying to figure out what was going on last night I used the browser debugger, in there you can watch network activity and see what URLs it is hitting. That's why I knew changing apiVersion was not enough and looked further in the code.

I need a forum to teach people a few of these little tools.

DamonNelton · ‎03-31-2021

We added the change to line 142, cleared cache and everything at first glance seems to be working now. Thanks for the help!

I'm hoping to upgrade from 10.8.0 to 10.8.1 very soon. If my memory is correct I think that will allow us to upgrade to API version 4 (my tech talk is not always spot on but I'm guessing you'll know what I mean). With API 4 that I assume will also help with some of the browser issues along the way?

Brian_Wilson · ‎03-31-2021

WAB is built on version 3 and they are never going to upgrade it to version 4 so no, changing to 10.8.1 or 10.9 won't change that.
The version 3 API is built on an outdated platform (called "Dojo") so the only way to switch over to JSAPI 4 is to switch to Experience Builder. We rely on widgets that are not ported to EXB yet so we're waiting on Esri for that.

DamonNelton · ‎04-01-2021

New development, after the change our web-apps now work but the pop-ups in our web-maps don't in Google Chrome. Still work in other browsers???

To further the mystery yesterday only my web-map pop-ups stopped working but they still worked for my other two GIS techs. Now this morning the pop-ups don't work for me and one of my techs with one tech still has everything working??

This is not the worst problem we've ever had but kind of frustrating behavior??