Open Bug 1531082 Opened 7 months ago Updated 5 months ago

Marionette test requires Internet connection to run?

Categories

(Testing :: Marionette, defect, P3)

Version 3
defect

Tracking

(Not tracked)

People

(Reporter: botond, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

I tried to run an Marionette test on the Android emulator while on a flight (with no internet access). It failed with the following exception:

W System.err: java.net.UnknownHostException: Unable to resolve host "firefox.settings.services.mozilla.com": No address associated with hostname
W System.err:    at java.net.Inet6AddressImpl.lookupHostByName(Inet6AddressImpl.java:125)
W System.err:    at java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:74)
W System.err:    at java.net.InetAddress.getAllByName(InetAddress.java:752)
W System.err:    at com.android.okhttp.internal.Network$1.resolveInetAddresses(Network.java:29)
W System.err:    at com.android.okhttp.internal.http.RouteSelector.resetNextInetSocketAddress(RouteSelector.java:187)
W System.err:    at com.android.okhttp.internal.http.RouteSelector.nextProxy(RouteSelector.java:156)
W System.err:    at com.android.okhttp.internal.http.RouteSelector.next(RouteSelector.java:98)
W System.err:    at com.android.okhttp.internal.http.HttpEngine.createNextConnection(HttpEngine.java:345)
W System.err:    at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:328)
W System.err:    at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:246)
W System.err:    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:457)
W System.err:    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:405)
W System.err:    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:243)
W System.err:    at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getInputStream(DelegatingHttpsURLConnection.java:210)
W System.err:    at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java)
W System.err:    at org.mozilla.gecko.switchboard.SwitchBoard.readFromUrlGET(SwitchBoard.java:442)
W System.err:    at org.mozilla.gecko.switchboard.SwitchBoard.loadConfig(SwitchBoard.java:119)
W System.err:    at org.mozilla.gecko.switchboard.AsyncConfigLoader.doInBackground(AsyncConfigLoader.java:54)
W System.err:    at org.mozilla.gecko.BrowserApp$9.doInBackground(BrowserApp.java:893)
W System.err:    at org.mozilla.gecko.BrowserApp$9.doInBackground(BrowserApp.java:890)
W System.err:    at android.os.AsyncTask$2.call(AsyncTask.java:304)
W System.err:    at java.util.concurrent.FutureTask.run(FutureTask.java:237)
W System.err:    at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:243)
W System.err:    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
W System.err:    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
W System.err:    at java.lang.Thread.run(Thread.java:761)
W System.err: Caused by: android.system.GaiException: android_getaddrinfo failed: EAI_NODATA (No address associated with hostname)
W System.err:    at libcore.io.Posix.android_getaddrinfo(Native Method)
W System.err:    at libcore.io.ForwardingOs.android_getaddrinfo(ForwardingOs.java:55)
W System.err:    at java.net.Inet6AddressImpl.lookupHostByName(Inet6AddressImpl.java:106)
W System.err:    ... 25 more

Note, the emulator was already downloaded and set up.

Do Marionette tests require an active internet connection for local runs? If so, can this requirement be avoided?

This appears to be an error originating from
org.mozilla.gecko.switchboard.AsyncConfigLoader.doInBackground
and not Marionette. Is this Fennec? Fenix/GeckoView?

(As somewhat of a digression, we do have a lot of tests that depend
on having an internet connection for no good reason. The cases
where a test explicitly requests something from a remote host is
easy to fix, but my experience has been that it’s more challenging
to correctly instrument the browser in a way that it avoid pinging
remote services. See https://bugzilla.mozilla.org/show_bug.cgi?id=1272255
for a bit more discussion on this topic. Again, this isn’t related
to this bug.)

Not sure what kind of service that is. But if it is not needed we should set services.settings.server to a dummy URL for Fennec only.

Blocks: 1371576
Priority: -- → P3

(In reply to Andreas Tolfsen ⦗:ato⦘ from comment #1)

This appears to be an error originating from
org.mozilla.gecko.switchboard.AsyncConfigLoader.doInBackground
and not Marionette. Is this Fennec? Fenix/GeckoView?

Fennec. The test harness hangs after this error, so I assume it's the cause.

Attached file Output from `mach marionette test` (obsolete) —

At the moment, I can't even get a marionette test to run successfully with an Internet connection (getting the attached output).

Flags: needinfo?(botond)

You have to use mach marionette-test to run the tests. marionette test was obsolete and I removed it recently.

What should I set as the value of the services.settings.server pref?

Flags: needinfo?(hskupin)
Attachment #9051833 - Attachment is obsolete: true

Above is the output from mach marionette-test after setting the mentioned pref.

And, for completeness, here is the patch I used to set the pref.

Assignee: nobody → botond
Assignee: botond → nobody
Comment on attachment 9054631 [details] [diff] [review]
Patch to set pref

Review of attachment 9054631 [details] [diff] [review]:
-----------------------------------------------------------------

::: testing/marionette/client/marionette_driver/geckoinstance.py
@@ +397,5 @@
>          # open additional tabs, the test harness tab itself might get unloaded
>          "browser.tabs.disableBackgroundZombification": True,
> +
> +        # Ensure blocklist updates don't hit the network
> +        "services.settings.server": "http://%(server)s/dummy/blocklist/",

This preference already gets set in the base GeckoInstance class, which is inherited by the Fennec specific one. So this addition shouldn't cause any difference in behavior.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #11)

::: testing/marionette/client/marionette_driver/geckoinstance.py
@@ +397,5 @@

     # open additional tabs, the test harness tab itself might get unloaded
     "browser.tabs.disableBackgroundZombification": True,
  •    # Ensure blocklist updates don't hit the network
    
  •    "services.settings.server": "http://%(server)s/dummy/blocklist/",
    

This preference already gets set in the base GeckoInstance class, which is
inherited by the Fennec specific one. So this addition shouldn't cause any
difference in behavior.

Perhaps I misunderstood your suggestion from comment 4, then:

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #4)

Mind adding the above mentioned preference from comment 2 to the following list, and check if that works?

https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/testing/marionette/client/marionette_driver/geckoinstance.py#377

Did you have something different in mind?

(In reply to Botond Ballo [:botond] from comment #12)

This preference already gets set in the base GeckoInstance class, which is
inherited by the Fennec specific one. So this addition shouldn't cause any
difference in behavior.

Perhaps I misunderstood your suggestion from comment 4, then:

Sorry, but that was my fault. I didn't check the base class at that point.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #4)

Mind adding the above mentioned preference from comment 2 to the following list, and check if that works?

https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/testing/marionette/client/marionette_driver/geckoinstance.py#377

Did you have something different in mind?

I actually see that the reason is Content process crashed (from your log in comment 5). Mind commenting out all MOZ_CRASHREPORTER_* env variables which get set by Marionette?

Also do you see the same behavior when not running a mobile but desktop build?

You need to log in before you can comment on or make changes to this bug.