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; } } }

Sporadic issue with Classic Web Maps not working in Chrome v.142.0.7444.60

JackBovee

Our Chrome web browsers happened to update overnight to version 142.0.7444.60. Now, whenever we try to access an WAB using the Classic Web Map Viewer (or any map using the Classic Web Map Viewer), none of our hosted layers are available. Everything is visible and functional still if you open the map in the new Map Viewer, but anything build with Classic seems to be broken atm.

We still haven't finished converting all our WAB applications over to Experience Builder yet, as I had assumed they would continue to work until next spring.

Finde mehr Beiträge mit dem Tag

Accepted answers

Charles_Blanchard

Hello @JackBovee,

This behaviour is due to an update in the way Chrome handles Local Network Access checks. You can read more about that update here: https://developer.chrome.com/blog/local-network-access.

For the time being, until the issue is fixed by Esri, you can utilize the following workaround. To avoid the inconvenience of having to constantly block or allow Local Network Access, you can go to chrome://flags/ and set Local Network Access Checks from Default to Disabled, which restores the behavior prior to the Chrome 142.x update.

Please feel free to reach out if you have any further questions!

Charles Blanchard

Associate GIS Analyst

Esri Canada

JackBovee

So IT just found out that there was a change in the x.60 build of Chrome that might be the root of the problem. There is apparently a Local Network Access check that's required to make this work.

All comments

JenniferMacLeod1

Hi Charles,

Is there a bug for this that we can follow? Just looking for confirmation that ESRI is aware and is working on a fix.

Thanks,

Jennifer

Charles_Blanchard

Hello Ryan,

My apologies for the delay in my response.

A general overview of the effect of the Chrome and Edge updates to the Local Network Access specification on ArcGIS Online and ArcGIS enterprise can be found at this link: https://support.esri.com/en-us/knowledge-base/what-to-know-about-new-permission-prompt-in-google-chro-000039171.

This article discusses the three main implementations of the software that require CORS requests to internal servers, these being:

iFrame Applications in ArcGIS Enterprise
- Apps like ArcGIS Enterprise Sites rely on iFrames to embed other ArcGIS Apps within the site.
Third-Party iFrame Integrations
- Adding ArcGIS Enterprise features that reference internal content like web maps directly to other sites through iFrames.
Applications in ArcGIS Online
- Apps like Experience Builder, used in ArcGIS Online that consume referenced services, like printing or geocoding services, from ArcGIS Server or ArcGIS Enterprise.

The key component here is the CORS requests to internal servers, which are a crucial component of the above functionalities. Unfortunately, these requests are now flagged by default by the new LNA specification, and thus bring up the prompt for end users.

For the time being, the LNA Adoption Guide provided by Google is an excellent resource to make the transition easier, and the article I linked above also includes this snippet from that guide specific to iFrames:

Add the local-network-access string to the iFrame configuration. This will ensure that the expected CORS request is sent out to the Enterprise portal for verification.

<iframe src="domainB.example" allow="local-network-access ‘DOMAIN’"></iframe>

I apologize for any inconvenience this problem has caused. Please feel free to reach back out if you have further questions, and I will do my best to address them.

Thank you,
Charles Blanchard
Associate GIS Analyst, Esri Canada

rgsteele-CoV

@Charles_Blanchard , are you able to answer my question, or is there someone else I can reach out to?

rgsteele-CoV

Hi Charles,

Can I please get an update on this? Our organization is seeing this issue where users accessing resources from sites on the arcgis.com domain are being prompted to allow the site to connect to devices on our local network.

We have opened a support request with ESRI only to be told that we need to create an exception to this security policy, with no further explanation provided. As a member of our organization's security team, I need to understand the rationale for your service to require this access.

Thanks!

Ryan

Charles_Blanchard

Hello @JackBovee,

This behaviour is due to an update in the way Chrome handles Local Network Access checks. You can read more about that update here: https://developer.chrome.com/blog/local-network-access.

Please feel free to reach out if you have any further questions!

Charles Blanchard

Associate GIS Analyst

Esri Canada

MichaelB25

I've been working on a similar problem this afternoon. Only in updated Chrome browser several of our imagery basemaps weren't displaying. Enabling "local network access" (either from pop-up, or "site information" icon to left of URL) resolves problem.

I'm guessing that AGOL apps are referencing what Chrome sees as the local network. This is a broad list, I'm guessing a local loopback may be to blamed, but unsure. See: https://wicg.github.io/local-network-access/#non-public-ip-address-blocks

cepsgis

This is impacting all services in web maps consumed by our EAM solution. Dashboards, surveys, and Experience Builders are also affected, and field staff are now reporting issues accessing data.

Jamie_Leitch_CNF

yes this solved my issue, thank you!

JackBovee

Interesting. I can see the point, but it's currently rather inconvenience. Didn't realize this had been in the works for some time.

I suppose that's going to impact anyone trying to access ArcGIS Online that's utilizing GIS resources that are hosted internally. Thankfully we're not a large county, but I envision this being an absolute nightmare for an urban area.

I'm assuming there's not really a viable solution on the hosting side to bypass this issue? It is odd it was only impacting the resources using the Classic Webmap Viewer.

JackBovee

The Chrome settings were in the browser itself, just to the left of the address bar.

George Thompson

Take a look at this Chrome blog: https://developer.chrome.com/blog/local-network-access

Jamie_Leitch_CNF

@JackBovee I am noticing issues with a Survey123 widget in an Experience Builder app in Portal (survey not accessible). This started after upgrading to Chrome 142.0.7444.60. Where did you access those settings?

JackBovee

So IT just found out that there was a change in the x.60 build of Chrome that might be the root of the problem. There is apparently a Local Network Access check that's required to make this work.

JackBovee

Just to confirm, you are running Chrome version 142.0.7444.60?

Looking at the Chrome console when trying to load up that particular WAB, this is the first of many errors that occurred:

All the errors appear to be due to "blocked by CORS Policy".

russell_roberts

I am not seeing this issue on the latest version of chrome using the web map and WAB app you provided. That error above makes it look like the services are either timing out or no longer accessible while the app is loading. If you are able to look at network or console logs while loading these maps and apps and catch any errors can help us see what the issue could be. I'll keep spot checking to see if I get any loading errors still.

JackBovee

Russ,

We only seem to be having the issues with Windows 11 and Chrome build 142.0.7444.60.

Here is one of the WAB applications that are having issues:
https://hubbardcounty.maps.arcgis.com/apps/webappviewer/index.html?id=405588666bba4397982b98b3fd382f62

Here's the underlying web map:
https://hubbardcounty.maps.arcgis.com/home/item.html?id=418bec418d7f475fb6957d53bc4fa468
Note that if you open it in the new Map Viewer, it works just fine. Only Classic seems to be having issues. Unfortunately, several of our older WAB applications do not play nice with the new Map Viewer, so we've been forced to use Classic.

Below is a screenshot of the errors we're getting when using Chrome of that build. Any of the County hosted layers are not working at all.

Also note that this is only impacted by Chrome Browsers on that particular build. Firefox and Edge appear to not have any issues currently. The previous Chrome build (v. x.59) also had no issues. I've not been able to fully test off network yet to see if it is an internal only issue.

russell_roberts

I am not able to reproduce the issue. If you have a map that is showing this and can share you can invite russell_jsapi to the group with the maps and layers and I'll take a look.

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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