+++ This bug was initially created as a clone of Bug #1551316 +++

In order to land bug 1551316, I'm going to disable another new webrtc test on android e10s, and I'm opening this follow up to address the wpt test situation on android e10s. 5 tests are currently disabled for a similar problem:

★ ~/moz/mozilla-central $ grep android testing/web-platform/meta/webrtc/*.ini 
testing/web-platform/meta/webrtc/RTCDTMFSender-ontonechange.https.html.ini:    if (os == "android") and e10s: bug 1550895 (frequently fails on geckoview)
testing/web-platform/meta/webrtc/RTCPeerConnection-restartIce.https.html.ini:    if (os == "android") and e10s: bug 1551316 (frequently fails on geckoview)
testing/web-platform/meta/webrtc/RTCPeerConnection-setRemoteDescription-tracks.https.html.ini:    if (os == "android") and e10s: bug 1550895 (frequently fails on geckoview)
testing/web-platform/meta/webrtc/RTCPeerConnection-transceivers.https.html.ini:    if (os == "android") and e10s: bug 1550895 (frequently fails on geckoview)
testing/web-platform/meta/webrtc/RTCRtpTransceiver.https.html.ini:    if (os == "android") and e10s: bug 1501562 (frequently fails on geckoview)
★ ~/moz/mozilla-central $ 

The problem is being discussed in bug 1544654, and seems to be that e10s piping is running out of file descriptors on android.

This bug is opened to look for short-term workarounds for now, e.g. restart-after as discussed in bug 1551316 comment 9.

Btw, this does not appear to be unique to WebRTC. I count 60 (!) tests that are disabled on android e10s for seemingly similar reasons.

It appears most of them were disabled in bug 1550895.

Thanks for opening this follow-up bug.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #1)

Btw, this does not appear to be unique to WebRTC. I count 60 (!) tests that are disabled on android e10s for seemingly similar reasons.

I wasn't around when most of these tests were disabled, but I'm pretty sure there was a variety of failure modes seen in the work on Bug 1550895, not just running out of fd's. Also, the android+e10s condition was sometimes being used in the metadata just to distinguish Fennec (no e10s) from GeckoView (e10s).

Good news, the restart-after: workaround appears to work.