Filed by: hskupin [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=71624592&repo=autoland https://queue.taskcluster.net/v1/task/cOa_MZ5-SoqyX7AI0VlF4Q/runs/0/artifacts/public/logs/live_backing.log We noticed this failure on bug 1323185 after pushing the patches to autoland. Here the list of failing jobs: https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-searchStr=mn&fromchange=96d0d062d97829e5e981ba7ca9fd1fe6fd0996e3&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable&tochange=b772206648a0 When the test fails we hang in getCurrentUrl(): > 1485283683541 Marionette TRACE conn611 -> [0,30,"setContext",{"value":"content"}] > 1485283683544 Marionette TRACE conn611 <- [1,30,null,{}] > 1485283683799 Marionette TRACE conn611 -> [0,31,"getCurrentUrl",null] > 1485283683911 Marionette DEBUG loaded listener.js > 1485283743669 Marionette DEBUG Closed connection conn611 The hang in getCurrentUrl() might come because under those conditions the test already starts with a remoteness tab, and also the newly opened one has remoteness turned on: > 1485283682715 Marionette TRACE conn611 <- [1,22,null,["2147483827","2147483838"]] > 1485283682718 Marionette TRACE conn611 -> [0,23,"switchToWindow",{"name":"2147483838"}] When the test passes the remote flags of both tabs are not set: > 1485283769725 Marionette TRACE conn610 -> [0,19,"getWindowHandles",null] > 1485283769726 Marionette TRACE conn610 <- [1,19,null,["249","268"]] > 1485283769736 Marionette TRACE conn610 -> [0,20,"switchToWindow",{"name":"268"}] > 1485283769738 Marionette TRACE conn610 <- [1,20,null,{}] This doesn't match what the test should be testing. We should stay in non-remoteness.

Mike, maybe you have an idea? The test is here: https://dxr.mozilla.org/mozilla-central/rev/fbdfcecf0c774d2221f11aed5a504d5591c774e0/testing/marionette/harness/marionette_harness/tests/unit/test_about_pages.py#80 Is it dependent on the current tabs remoteness state which state a newly opened tab will have?

Strange. The only way that a previous tab might influence the remoteness of a newly created tab would be if the initial tab was non-remote in a window that is remote by default, and the user clicks on a link in that tab which opens up a new tab. The newly created tab will also be non-remote in that case. I can't think of any other cases.

This hasnt happened since March so closing

The signature of this test failure has been changed, and the test is still marked as skipped. Sorry, that I forgot to disable it via bug 1291320. With my patch on bug 1368101 it should be fixed.

This is fixed now.

Moving bug to Testing::Marionette Client and Harness component per bug 1815831.