I've also noticed the user agent states "Android 8.1.0" although my device is running Android 9 so that is also a bug probably.

@cernilovsky: Could you please elaborate above steps to reproduce. Please let us know how to set custom user agent. Sample apk and screencast on reproducing would help in further triaging.

Thanks!

I've been working on it, please give me few days, it isn't so easy to reproduce as I thought. Thanks!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Your device isn't running Android 9: the build ID in the screenshot starts with OPM8 which is Android 8.1, as the UA says.

Do you control the sites you're loading here, or are they someone else's? Do you know if the sites use a service worker? (it's possible that service worker initiated requests aren't going to use the useragent because they aren't associated with a specific webview)

@torne: You are right, my bad, I got confused by my Pixel C having Android 8.1 and Pixel running Android 9.

I have discovered the bug is caused by the following:
1. There must be multiple WebViews. If only one WebView loads the page the User-Agent shows correctly.
2. The websites inside these WebViews have to send custom messages to WebViews via JavaScript's window.location.href="...". WebViews intercept these messages via shouldOverrideUrlLoading().
3. The websites load some other resources via AJAX, but I believe this can also affect non-XHR requests.

In the attachment you can find some screenshots, the sample app's APK and source code with sample web source code. Regarding the sample app, all the important code can be found in MainActivity.kt. Note that the bug is random so the results may be different every time you run the app.

Deleted: app-debug.apk 2.1 MB

app-debug.apk 2.1 MB Download

Deleted: device-2018-10-25-102153.png 918 KB

	device-2018-10-25-102153.png 918 KB View Download

Deleted: device-2018-10-25-102217.png 1004 KB

	device-2018-10-25-102217.png 1004 KB View Download

Deleted: web.zip 1.3 KB

web.zip 1.3 KB Download

Deleted: WebviewUserAgentBug2.zip 706 KB

WebviewUserAgentBug2.zip 706 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Note: If you have trouble building the sample app, just delete the assets folder, it is not necessary for running the app.

I can't repro with your compiled APK. Tried ~5 times on my device with 70.0.3538.110 and ~5 times with 69.0.3497.100. Any ideas for an easier repro?

I was able to to reproduce it in Google Pixel C, Pixel 1 and Samsung Galaxy S9, but not in Sony Xperia XZ (all with newest Chrome and available Android). It seems the bug is hardware dependent. It took me 2 weeks to find the real cause and make this sample app + web so I got no ideas for an easier repro except trying a different device, e. g. one of those stated above.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the info.

Test team: does anyone have bandwidth to try to repro on Pixel C and do a per-build bisect? Per-CL would also be great, if possible.

As per comment#9 bug is random and results will be different everytime we run the app so unable to find per-build bisect.Could anyone help in finding actual and expected behavior with repro steps.
Thanks!

Bug is random on all the builds even on M68  so it gets difficult to find the per-build & per-cl bisect.Tried on M69 ,M70& M71 and while we try to clear the app, randomly it is happening .Please share the good& bad behaviour with a video.Thanks.

cernilovsky@ what is the expected repro rate for your test app on Pixel C?

It is near 100 %, see the video: https://photos.app.goo.gl/FWmNLD7ojuLgxmgQ7
As you can see in all three cases most WebViews incorrectly showed the default user agent instead of the custom one, in the second case the custom and default agents were mixed together.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Given this has a very high repro rate, could testers try to bisect?

Expected result: every WebView says "Custom user agent string"
Buggy result: at least 1 WebView says "Mozilla 5.0... " etc. (the default user agent)

Please let me know if we do not observe a very high repro rate as seen in the video.

#21 - We will try to bisect and update.

+alekyoo for help with bisect

https://chromium.googlesource.com/chromium/src/+log/69.0.3497.2..68.0.3440.134?pretty=fuller&n=10000 
per CL bisect im having issues, still working on it. Will update later

^ That range looks suspicious. 69.0.3497.2 is (conventionally speaking) higher than 68.0.3440.134. Technically, there are some CLs in 68...134 that didn't make it in 69...2, but I would be surprised if our bisect script can actually identify such a range.

per build bisect: https://chromium.googlesource.com/chromium/src/+log/68.0.3440.134..69.0.3497.2?pretty=fuller&n=10000 

per CL bisect: 
You are looking for a change made after 571542(GOOD), but before 571543(BAD).

https://chromium.googlesource.com/chromium/src/+/afde76d6ab1d064821294da9d31cd626cbf8581a
AND
https://chromium.googlesource.com/chromium/src/+/afde76d6ab1d064821294da9d31cd626cbf8581a

New per build range: https://chromium.googlesource.com/chromium/src/+log/69.0.3475.4..69.0.3476.0?pretty=fuller&n=10000 

per CL range is pointing to this: 
https://chromium.googlesource.com/chromium/src/+/8962649114490c145c5cba76fe290752014d6432 showing me this
You are looking for a change made after 571042(GOOD), but before 571170(BAD).

https://chromium.googlesource.com/chromium/src/+log/f90a0855264592f514c1dd8529460f01f5e93bf0..8962649114490c145c5cba76fe290752014d6432 all changes were made between good and bad builds

8962649114490c145c5cba76fe290752014d6432 is not a likely culprit. https://chromium.googlesource.com/chromium/src/+log/f90a0855264592f514c1dd8529460f01f5e93bf0..8962649114490c145c5cba76fe290752014d6432 is a bit narrower than the per-build range.

aluo@ why can't the per-cl script narrow the range further? The script should *not* point to an individual CL if the range is wide (if the script does not have such output, perhaps we can improve the output to clarify what testers should post to the crbug).

At this point, I'd rather see a trustworthy (and narrow) per-cl bisect range before we pass to devs for further investigation. If such a range is impossible, please explain and pass back to the bugcop queue. I'm passing to aluo@ to investigate why the script is acting up, and if we can get better results here.

All the builds used for the per-cl-bisect between 571042 and 571170 are missing, possibly due to the builds not compiling in that range or something went wrong with the builder that builds them, but I don't know since the old logs are gone.  The tool prints out both good and bad builds in the case that the range contains more than 1 commit such as what happened here.  

alekyoo@, assigning back to you to make sure the range is correct though, let's chat tomorrow.

alekyoo@ confirmed that the repro is consistent on the good and bad builds.