Update 6/28/24: Have received several more screenshots of affected phones' system details to provide to Esri Engineers.
The problem is getting worse... Recently Firefox --the workaround was to install and use a non-Chromium browser, started exhibiting the blank map bug too, for some but not all users experiencing the problem in Chrome. So, Update Creep is biting us.
Bug has been escalated, has a status of "...added to the backlog, to be addressed in near-term release."
https://my.esri.com/#/support/bugs/bugs?bugNumber=BUG-000166041
UPDATE 4/30/24: Investigation show that Javascript 4.29 may be at the heart of this problem. An Esri engineer and my colleague who are working through this found rolling back to JS 4.27 in a test app resolves the map-blanking-on-zoom problem. Now, how to fix Experience to work correctly with 4.29, or get the relevant open-source community (?) to fix JS if the problem is not just Esri's products?
Updated 5/6/24: A Samsung S22 has the same problems and tested out the same way on a 4.27 SDK test version, that the problem is likely how ExB handles JS 4.29.
...................................................................................................
With thanks to OP @DavidColey , and @TonghuiMing, for their contributions, I'll chip in anew to bump the thread. This remains an issue. My org is attempting to communicate with Esri at a higher level but we have not many facts to go on.
But I'll add a few more facts to the collection, to help Esri in resolve this ongoing issue...
David pointed out that updating phones' OSs may resolve the issue, so I'm open to the idea that this may be an Alphabet Inc. problem and not an Esri problem. But we'll need help in outreach to Alphabet if that is where this needs to go.
In my group alone, 2 out of 12 testers of EB apps on various phones encountered the Chrome-browser-goes-blank-on-zoom issue on two related but different apps. I have a high-visibility EB app in "Beta" at the moment that is being held back and overdue for full public implementation over this problem. (iOS has no reported issue of this kind; Firefox on Android works without issues [Note 1], but that is not a good solution to tell users they need to load and use Firefox just for our app.)
In this app: https://arcg.is/0ivqPS
With the default settings as-published, the blank-map behavior is found to occur on zoom closer-in than "10 mi", or "2 mi", or even closer-in under another visibility circumstance, on two different model Samsung Android phones, in Chrome and Samsung's own browser simply called "Internet": A42 and S10e. (Firefox does not exhibit the behavior on either phone.)
- Sam S10e OS etc., trying to get that info...
- Sam A42 Android OS V. 13, Baseband V. A426USQS8EXB2, Kernel 4.19.152-perf-... dated 22-Feb., Security SMR Jan 2024 R1 ...more. Software update dated 2-Mar 2024 A426USQS8EXB2 insists it is current.
- Almost identical Sam A32 does NOT exhibit the problem: Android OS V. 13, Baseband V. A326U1UESDDXC2, Kernel 4.14.186-27095505 dated 14-Mar., Security: SMR Mar-2024 R1 ...more. Last successful update 3 Ap 2024 (but testing prior did not show our issue) A326U1UESDDXC2.
Interestingly, the behavior resolves if the number of Map Layers selected as visible=1 is reduced from the default for our app of 20, and that final max number is variable dependent on the zoom level.
Set to ~7 or 8 layers visible, map visibility returns at 10 mi... until you get under 2 mi. Then map visibility resolves again if visibility is reduced to 6 or 5 or fewer Layer, then goes away again at 2000' with more un-checks getting the map back visible.
Example https://arcg.is/znLP
At this view of the app, zoomed in to 1000' and only 6 of the 20 standard layers in this EB app checked, the visibility problem abates (but there is a screen flicker on adding the 6th). Check visibility=1 on another layer and it's back to blank-map. Zoom out to 2mi and the map renders (maybe), but add an 8th layer, and we're back to blank-map. Out to 10 mi, we're back to visible; the app can render a map for 9 but not 10 layers, etc. (Visibility by Layer is tuned variably in the Web Map for features to start coming in at 20mi, then 10mi, etc. for different features filtered on a linear feature's type such as a road versus a trail).
I suppose our app is asking a lot of the EB platform. One linear class gets 10 Filtered cases to distinguish and make each case separately-selectable for visibility in Map Layers. But these filters are set in the Web Map, not on the Experience app. And Filtering does not appear to be at issue: In a temporary version of our app with no special filtering on the linear class in its Web Map, the blank-map behavior in its EB app is about the same-- 7 layers max allowed at 5000'. See https://arcg.is/1PWr9H1
Thing is, 20 or more visible layers was never an issue with our /webappviewer/ version of our map site, which we are scrambling to replace as the tech ages-out and we've been moved onto AGOL away from a soon to be retired Portal server.
One last detail: Pulling in REST services as optional layers may or may NOT add to the number of visible layers that tips the app over to blank-screening. I cannot put my finger on the theme as to why (play with our visibility settings of Optional Layers and you'll see the variability). May be a difference between a service being consumed from a Hosted Feature Service versus older tech Map Service?
. . . . . .
Note 1: Firefox mobile has an annoying auto-refresh "feature" which resets the app every time you tab away to another app then return to the browser. A solution is turning on all Manage URL options settings in the EB project, which solves the problem by having the page refresh to the exact view and visibility settings last set for the app as contained in the extensive URL parameters these settings drive.
