1334137 - Intermittent test_navigation.py TestNavigate.test_type_to_non_remote_tab | IOError: Process killed because the connection to Marionette server is lost. Check gecko.log for errors (Reason: Connection timed out after 60.0s) - Hang in getCurrentUrl()

Status: RESOLVED FIXED

(Testing :: Marionette Client and Harness, defect)

Description

[Treeherder Bug Filer]

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.

Comment 1

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

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?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 3

[David Burns :automatedtester]

This hasnt happened since March so closing

Comment 4

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

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.

Comment 5

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

This is fixed now.

Comment 6

[BMO Automation]

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