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

RESOLVED WORKSFORME

Status

Testing
Marionette
--
major
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: zac, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 713338 [details]
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.
(Reporter)

Comment 1

5 years ago
Created attachment 713339 [details]
Test case to replicate tearDown failure
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.
Summary: [B2G] Test tearDown fails when a sleep is introduced into it → [B2G] test_call_contact fails when a sleep is introduced into it
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.
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.
(Reporter)

Comment 5

5 years ago
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.
(Reporter)

Comment 6

5 years ago
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?
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.
Blocks: 801898
(Reporter)

Comment 8

4 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.