1839583 - GeckoView fails to load initial page as specified via an intent

Status: RESOLVED WORKSFORME

(GeckoView :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: adb logcat output

While investigating the problem on bug 1838381 I noticed that when we start the TestRunner application on Android and pass a URL it's not getting loaded. As result the opened tab stays on the initial document, which is about:blank. The command that I was using here is:

adb shell am start -a android.intent.action.VIEW -n org.mozilla.geckoview.test_runner/.TestRunnerActivity -d http://mozilla.org

I've attached a log from adb in case it helps to figure out what's wrong here. Interestingly this command seems to work for Olivia. Not sure if it matters but I'm using an artifact build of the TestRunner.

Comment 1

[Olivia Hall [:olivia]]

Thanks for filing this bug! When I tested the intent I was using the moz-emulator aarch64 emulator with API level 30 using a non-artifact build.

This network issue stands out to me when comparing with my logs:

06-21 10:38:22.708   869  3703 D NetworkMonitor/102: PROBE_DNS connectivitycheck.gstatic.com 12511ms FAIL in type ADDRCONFIG Timeout
06-21 10:38:22.708   869  3702 D NetworkMonitor/102: PROBE_DNS www.google.com 12511ms FAIL in type ADDRCONFIG Timeout

Not quite sure how to debug this, but my PROBE_DNS always is showing OK in the logs. Could be a setting or permission difference somewhere.

Could you tell me if it is the moz-emulator, API level, and confirm the device architecture?
(adb shell getprop | grep "ro.odm.product.cpu.abilist\|ro.kernel.qemu.avd_name\|ro.system_ext.build.version.sdk" )

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I'm using aarch64 as well via a M1 MacBookPro from last year. Here the output of the command you mentioned:

[ro.kernel.qemu.avd_name]: [mozemulator-arm64]
[ro.odm.product.cpu.abilist]: [arm64-v8a]
[ro.odm.product.cpu.abilist32]: []
[ro.odm.product.cpu.abilist64]: [arm64-v8a]
[ro.system_ext.build.version.sdk]: [30]

Also should GeckoView by default stops after loading the initial document (about:blank) when starting GeckoView, or should it load about:blank asynchronously right after as well similar to Firefox on desktop?

Comment 3

[Olivia Hall [:olivia]]

I tested this some today with both a full build and an artifact build, but didn't have any differing behavior. I did see some differing behavior with http/https on the full build and saw a white page with "error" on it once when trying to load a http website.

Also should GeckoView by default stops after loading the initial document (about:blank) when starting GeckoView, or should it load about:blank asynchronously right after as well similar to Firefox on desktop?

I'm not entirely sure what the expected behavior should be. :m_kato, do you know what the expected behavior should be in GeckoView for the Test Runner?

Comment 4

[Makoto Kato [:m_kato]]

I cannot reproduce this on x86_64 API30 image, so although I don't know why, GeckoViewNavigation.onLocationChange isn't called according to your log.. So document isn't loaded correctly.

06-21 10:38:17.826   485   485 E netmgr  : qemu_pipe_open_ns:62: Could not connect to the 'pipe:qemud:network' service: Invalid argument
06-21 10:38:17.826   485   485 E netmgr  : Failed to open QEMU pipe 'qemud:network': Invalid argument

It seems to network error.

Comment 5

[Makoto Kato [:m_kato]]

-dns-server option for emulator can help it, but I guess there is no way to add it by ./mach android-emulator

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks for the feedback! That is indeed the problem here. When I'm using a local address it works fine. So I assume the DNS setup with Adguard is playing tricks here. But given that loading a local address works fine I didn't try to find out how to set the DNS.

I think that we can close this bug as WFM.