840931 - [B2G] test_call_contact fails when a sleep is introduced into it

Status: RESOLVED WORKSFORME

(Remote Protocol :: Marionette, defect)

Description

[Zac C (:zac)]

Attachment: logcat

If a sleep is introduced into the tearDown then the tearDown fails.

Jgriffin suggested that this is the B2G app process failing.

To replicate run the attached test case. The teardown should fail reliably ,verified across several devices and builds.

With the sleep removed the test will pass reliably.

This has been seen on CI and usually disrupts the following tests so I'm considering it a reasonably high priority or at least a good preventative measure if we can debug and avoid this condition.

Comment 1

[Zac C (:zac)]

Attachment: Test case to replicate tearDown failure

Comment 2

[Dave Hunt [:davehunt] [he/him] ⌚BST]

It appears this is not related to tearDown. Waiting 5 seconds after tapping hang up causes any subsequent Marionette calls to fail. I suspect it's something to do with the active app switching from phone back to contacts.

Comment 3

[Jonathan Griffin (:jgriffin)]

Thanks for the logcat.  This is indeed a B2G process crash.  You can see this in the log:

E/GeckoConsole(  108): [JavaScript Error: "[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMessageSender.sendAsyncMessage]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://marionette/content/marionette-actors.js :: MDA_sendAsync :: line 204"  data: no]" {file: "chrome://global/content/devtools/dbg-server.js" line: 557}]

The NS_ERROR_NOT_INITIALIZED error in response to sendAsyncMessage means that the iframe we're attempting to send a message to has crashed.

Comment 4

[Jonathan Griffin (:jgriffin)]

I suppose it's also possible we could get this error when the frame has closed expectedly; i.e., if active app spontaneously closes in order to switch to another.

Zac, can you increase the delay to something like 30s, and attempt to play with the UI manually after 5?  If the UI works, then it's likely we're attempting to send the message to a closed frame, rather than a crashed one.

Comment 5

[Zac C (:zac)]

This test is doing that; closing the call screen (when hanging up the call) which is in its own frame, so perhaps Marionette is not detecting the closure of the frame. 

I tried your suggestion and the UI is active and seems to be fully functional.

Comment 6

[Zac C (:zac)]

I just tried putting in a switch_to_frame() right after the hangup step and the test passes fine even with the sleep.
So it seems Marionette is losing track of the frame?

Comment 7

[Jonathan Griffin (:jgriffin)]

Marionette doesn't handle the case very well when the active frame disappears.  I have some ideas on how to improve this, which I'll look at after spending some more time on the app-freezing problem.

Comment 8

[Zac C (:zac)]

Through various other bugs the Marionette handling of dropped frames was improved. I don't believe this bug to be valid anymore, these scenarios work now.