Loading the webapp fails on with WebView version 74

[mrjones-plip]

Describe the bug
Starting at CHT 4.2.0, when a self hosted CHT instance uses nginx as it's front end, certain Android devices fail with a console error Uncaught SyntaxError: Unexpected token ? main.js:1

To Reproduce
Steps to reproduce the behavior:

1. Install CHT Core 4.2.0 in docker helper. Do not use AWS ELB
2. Using CHT Android 1.0.1 with webview 74 or lower, connect to CHT Core
3. See error in console Uncaught SyntaxError: Unexpected token ? main.js:1 and see full screen spinner.

Expected behavior
You should be prompted to log in to the CHT with no errors in console

Screenshots

Console tab

Network tab

Security tab

Environment

• Instance: local dev
• Browser: CHT Android 1.0.1 WebView 74 or 68
• Client platform: See above
• App: webapp
• Version: 4.2.0 and above

Additional context
This was discovered while testing #8278. It's assumed that this wasn't caught earlier because we test on Gamma which uses AWS ELB to terminate TLS. Indeed, testing CHT COre 4.2.0 on Gamma with the exact same handset as above works. Testing on 4.1.0 and 4.0.0 on the same handset also work.

Also, testing the same 4.2.0 instance with WebView 111 worked fine. All desktop browsers worked as well.

[garethbowen]

This may be resolved by setting a higher minimum browser version as part of #7448 but we don't currently know the upper bound on this issue so we need to look into it regardless.

@mrjones-plip It looks like this is happening after login - is that correct?

[mrjones-plip]

@garethbowen - no this happens before login - steps above to reproduce are correct!

[dianabarsan]

I believe what is happening here is that Tatiana is navigating to root, which attempts to load the main code (main.js,. scripts.js). This code is responsible for checking whether the user is logged in and eventually redirect them to login.

[mrjones-plip]

Ah - thanks @dianabarsan !

We're using unbranded and entering the URL of the docker helper instance - so it's what ever default behavior of CHT Android unbranded in this case.

[dianabarsan]

I believe this is because of the Angular upgrade: #7992 we did in 4.2
#7999 (comment)

I've updated the .browserlistrc and the isUsingSupportedBrowser function from the browser detection services to support chrome v80 which includes the features of es2020.

[dianabarsan]

I'm not sure we can do anything about this, unfortunately, and we were already aware of this issue - we even discussed with @craig-landry, @garethbowen and @kennsippell post ZNZ meetup.

[mrjones-plip]

ah - thanks for the research into the cause being the angular bump to 15 in CHT 4.2 @dianabarsan! I think a reasonable remediation is to detect WebView <80 and alert that we're not compatible. I know we did a bit of this work in #7448, but should complete the effort with the recently filed #8159.

Given this is "working as designed" per your comment re ZNZ meetup, do we feel this is still a bug then? Maybe just close this in favor of #8159?

[mrjones-plip]

@kennsippell - curious on your thoughts as you're closer to what the field and live deployments sees things as. Further, I know you've explored client telemetry and what folks are actually running!

[dianabarsan]

I don't think there's anything to do about this. I know @latin-panda investigated at the time of the Angular upgrade and it was not possible to produce old ES transpiled versions of the code (due to Angular dropping support for IE11).

So I'm ok to either retag this (so it doesn't block 4.3.0) or close it according to @mrjones-plip 's comment above.

[garethbowen]

@mrjones-plip Do we have any data on what versions do work? Is 80 ok?

[mrjones-plip]

We know for sure 95 works on my Android 5.1 device and QA had an Android 9 device with 79 that failed and then upgraded to latest (accidentally) and started working. Only two data points, but coupled with Diana's research, 80 sounds correct to me.

@garethbowen - I propose remove the Affects:* labels, remove from 4.3.0 release, closing this ticket and focusing on #8159

[garethbowen]

@mrjones-plip I agree. My only concern is that 74 is higher than the previously communicated 72. However we're starting to make good progress on testing and communicating browser support versions better...