Mark Banner (:standard8) Reporter
	Description • 9 years ago

In the Loop functional tests, we sometimes the functional tests fail, when we do we get:

 2:31.24 LOG: MainThread WARNING Failed to gather test failure debug.
Traceback (most recent call last):

  File "/Users/mark/loop/gecko-dev/testing/marionette/client/marionette/runner/base.py", line 537, in gather_debug
    rv['screenshot'] = marionette.screenshot()

  File "/Users/mark/loop/gecko-dev/testing/marionette/client/marionette/marionette.py", line 1587, in screenshot
    id=element, highlights=lights)

  File "/Users/mark/loop/gecko-dev/testing/marionette/client/marionette/decorators.py", line 36, in _
    return func(*args, **kwargs)

  File "/Users/mark/loop/gecko-dev/testing/marionette/client/marionette/marionette.py", line 634, in _send_message
    self._handle_error(response)

  File "/Users/mark/loop/gecko-dev/testing/marionette/client/marionette/marionette.py", line 666, in _handle_error
    "Malformed packet, expected key 'error' to be a dict: %s" % response)

MarionetteException: MarionetteException: Malformed packet, expected key 'error' to be a dict: {u'message': u'doc is undefined', u'error': u"error occurred while processing 'takeScreenshot"}

This is presumably trying to take a screenshot of the failure (which is a errors.NoSuchElementException).

I had a poke in "takeScreenshot" but couldn't see where 'doc' was in the code. I also didn't see any errors in the browser console when I added in a sleep just before this exception is raised.


To run the tests, you can run the latest mozilla-central with:

LOOP_SERVER=https://loop-dev.stage.mozaws.net ./mach marionette-test browser/components/loop/test/functional/manifest.ini

I'm running with http://hg.mozilla.org/mozilla-central/rev/940118b1adcd

To make a test fail, I changed browser/components/loop/test/functional/test_1_browser_call.py like this:

     def check_remote_video(self):
         video_wrapper = self.wait_for_element_displayed(
             By.CSS_SELECTOR,
-            ".media .OT_subscriber .OT_widget-container", 20)
+            ".media .OT_subscriber .OT_fake-container", 20)

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 1 • 9 years ago

I have seen the same with our upcoming Firefox UI tests. In most cases this is happening because the underlying window does no longer exist. A switch_to_window() call helped in all of our cases. Are any of those failing tests handling tabs or chrome windows?

	Mark Banner (:standard8) Reporter
	Comment 2 • 9 years ago

The one I've seen today is where we have just done:

self.marionette.set_context("content")

That's switch back from a chrome perspective to a content tab. Hence, I don't see how that couldn't exist in our tabs.

	Andreas Tolfsen ❲:ato❳
	Comment 3 • 9 years ago

:standard8, do you execute takeScreenshot in chrome- or in content context?

I think it fails in relation to get the first window element here: https://dxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-server.js?from=marionette-server.js#2661

It looks like the takeScreenshot method isn't safe-guarded against errors that are thrown.  This will be fixed by bug 1107706.  The error we see sent back here comes from the devtools transport server which has a catch-all for unhandled errors.

(In reply to Henrik Skupin (:whimboo) from comment #1)
> I have seen the same with our upcoming Firefox UI tests. In most cases this
> is happening because the underlying window does no longer exist. A
> switch_to_window() call helped in all of our cases. Are any of those failing
> tests handling tabs or chrome windows?

It's still a Marionette bug that doc is undefined.  We should catch that and send back a sensible error message.

	Mark Banner (:standard8) Reporter
	Comment 4 • 9 years ago

(In reply to Andreas Tolfsen (:ato) from comment #3)
> :standard8, do you execute takeScreenshot in chrome- or in content context?
> 
> I think it fails in relation to get the first window element here:
> https://dxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-
> server.js?from=marionette-server.js#2661

In this case I believe we're in content context.

The bit we had fail was:

http://hg.mozilla.org/mozilla-central/file/7c87286ce969/browser/components/loop/test/functional/test_1_browser_call.py#l130

and this is called from standalone_check_remote_video just after a call to switch to content context:

http://hg.mozilla.org/mozilla-central/file/7c87286ce969/browser/components/loop/test/functional/test_1_browser_call.py#l89

Note we also have switch_to_panel and switch_to_chatbox which will be operating in the chrome context, prior to this call, but this call should reset us back I believe.

	Andreas Tolfsen ❲:ato❳
	Comment 5 • 6 years ago

Since Loop is no longer a thing we have no way of reproducing this.