969126 - Marionette JavascriptException: TypeError: mm is null

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Garrett Robinson [:grobinson]]

When I run "./mach mochitest-remote content/base/test/csp/test_CSP.html", I get:

Traceback (most recent call last):
  File "/home/garrett/B2G/objdir-gecko/_tests/testing/mochitest/runtestsb2g.py", line 140, in run_tests
    self.runner.start(outputTimeout=timeout)
  File "/home/garrett/B2G/../mozilla-central/testing/mozbase/mozrunner/mozrunner/remote.py", line 178, in start
    self.marionette.execute_script(script.read(), script_args=self.test_script_args)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 1108, in execute_script
    filename=os.path.basename(frame[0]))
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 613, in _send_message
    self._handle_error(response)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 648, in _handle_error
    raise JavascriptException(message=message, status=status, stacktrace=stacktrace)
JavascriptException: JavascriptException: TypeError: mm is null
stacktrace:
	execute_script @remote.py, line 178
	inline javascript, line 68
	src: "  mm.addMessageListener("SPPrefService", specialPowersObserver);"

Mochitest ERROR | Automation Error: Received unexpected exception while running application

This is a recent regression from Bug 945268, which made the CSP tests pass on B2G/e10s. It seems like it might be related to the changes made in Bug 951895, which were required to hook up the Message Manager for iframes loaded in a different process.

Comment 1

[Garrett Robinson [:grobinson]]

This bug disturbs me because the changes to testing/mochitest/b2g.json from Bug 945268 should have made these tests enabled by default. How is it possible that these tests are breaking when run locally (in the emulator with mach mochitest-remote) but are not orange on TBPL?

Comment 2

[Jonathan Griffin (:jgriffin)]

(In reply to Garrett Robinson [:grobinson] from comment #1)
> This bug disturbs me because the changes to testing/mochitest/b2g.json from
> Bug 945268 should have made these tests enabled by default. How is it
> possible that these tests are breaking when run locally (in the emulator
> with mach mochitest-remote) but are not orange on TBPL?

In TBPL, these tests are run after lots of other tests.  It's possible that some other test run before it is changing state in such a way that it allows these tests to pass.

It's also possible that they're passing in TBPL because they're running inside an iframe; when you run an individual test by itself, that doesn't happen.  You could try running the test directory locally, instead of the single file...that way you'll get the same iframe that is used in TBPL.

Comment 3

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/eb8002584068

Comment 4

[Garrett Robinson [:grobinson]]

Was closing this a mistake? How does the linked commit resolve this issue?

Comment 5

[Eric Rahm [:erahm]]

Agreed, that was unrelated from bug 969129

Comment 6

[Carsten Book [:Tomcat]]

(In reply to Garrett Robinson [:grobinson] from comment #4)
> Was closing this a mistake? How does the linked commit resolve this issue?

yeah the merge tool just take the bug number and include then the commit rev and does the changes like resolving. Seems in the https://hg.mozilla.org/mozilla-central/rev/eb8002584068 commit the wrong bug number (this bug) was included. will move the comment to bug 969129

Comment 7

[Garrett Robinson [:grobinson]]

(In reply to Jonathan Griffin (:jgriffin) from comment #2)
> It's also possible that they're passing in TBPL because they're running
> inside an iframe; when you run an individual test by itself, that doesn't
> happen.  You could try running the test directory locally, instead of the
> single file...that way you'll get the same iframe that is used in TBPL.

AIUI, single tests also run inside an iframe and there shouldn't be a difference between single and multiple test's iframes. Either way, the problem persists when I try to test the whole directory:

$ ./mach mochitest-remote content/base/test/csp

1392052705451	Marionette	INFO	sendToClient: {"from":"0","error":{"message":"TypeError: mm is null","status":17,"stacktrace":"execute_script @remote.py, line 178\ninline javascript, line 68\nsrc: \"  mm.addMessageListener(\"SPPrefService\", specialPowersObserver);\""}}, {967afe2e-f646-4694-a938-a312516efc80}, {967afe2e-f646-4694-a938-a312516efc80}
Traceback (most recent call last):
  File "/home/garrett/B2G/objdir-gecko/_tests/testing/mochitest/runtestsb2g.py", line 140, in run_tests
    self.runner.start(outputTimeout=timeout)
  File "/home/garrett/B2G/../mozilla-central/testing/mozbase/mozrunner/mozrunner/remote.py", line 178, in start
    self.marionette.execute_script(script.read(), script_args=self.test_script_args)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 1114, in execute_script
    filename=os.path.basename(frame[0]))
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 613, in _send_message
    self._handle_error(response)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 648, in _handle_error
    raise JavascriptException(message=message, status=status, stacktrace=stacktrace)
JavascriptException: JavascriptException: TypeError: mm is null
stacktrace:
	execute_script @remote.py, line 178
	inline javascript, line 68
	src: "  mm.addMessageListener("SPPrefService", specialPowersObserver);"


Mochitest ERROR | Automation Error: Received unexpected exception while running application

So, I'm still concerned that these test failures were not caught on TBPL. How can I be sure that these tests are in fact running? (perhaps there is another blocking mechanisms, besides b2g.json, that I'm not aware of).

Comment 8

[Jonathan Griffin (:jgriffin)]

You can inspect some of the current TBPL logs, see e.g., https://tbpl.mozilla.org/php/getParsedLog.php?id=34417891&tree=Mozilla-Central&full=1, and search for "test_CSP", which is in fact present and running.

As far as your local problem, can you give some more details about your OS/hardware, since that may be relevant?

Comment 9

[Garrett Robinson [:grobinson]]

I'm on Linux (Mint 16 a.k.a Ubuntu 13.10) and I'm running mochitests in the emulator with "./mach mochitest-remote".

Comment 10

[Jonathan Griffin (:jgriffin)]

How much RAM, and are you running on an SSD?

Comment 11

[Garrett Robinson [:grobinson]]

8GB, yes. (Thinkpad X1 Carbon, ~1 year old).

Comment 12

[Jonathan Griffin (:jgriffin)]

I think this is a race condition; we are probably executing the script that's erroring out too quickly, right after we start B2G:

http://mxr.mozilla.org/mozilla-central/source/testing/mozbase/mozrunner/mozrunner/remote.py#175

I'd guess if you added a time.sleep(15) before the above line, the problem would go away.

What we need to do is update the startup script to wait for the test container app to actually be launched and top-most before we try to get the app's message manager.

Comment 13

[Andrew Halberstadt [:ahal]]

Should we just call emulator.wait_for_homescreen() before launching the script?

Comment 14

[Andrew Halberstadt [:ahal]]

Attachment: wait_for_homescreen

Garrett, could you try this patch and see if it works? Shouldn't need to rebuild.

Comment 15

[Jonathan Griffin (:jgriffin)]

(In reply to Andrew Halberstadt [:ahal] from comment #13)
> Should we just call emulator.wait_for_homescreen() before launching the
> script?

Very likely that would be enough.

Comment 16

[Garrett Robinson [:grobinson]]

(In reply to Andrew Halberstadt [:ahal] from comment #14)
> Created attachment 8374035 [details] [diff] [review]
> wait_for_homescreen
> 
> Garrett, could you try this patch and see if it works? Shouldn't need to
> rebuild.

Unfortunately, it does not work, although I do get a different error message:

MARIONETTE LOG: INFO: waiting for mozbrowserloadend
###################################### forms.js loaded
############################### browserElementPanning.js loaded
######################## BrowserElementChildPreload.js loaded
*** UTM:SVC TimerManager:notify - notified @mozilla.org/b2g/webapps-update-timer;1
1392148836913	Marionette	INFO	sendToClient: {"from":"0","error":{"message":"timed out","status":28,"stacktrace":null}}, {eb6f86ce-ae1e-4035-ae15-c09757155fd8}, {eb6f86ce-ae1e-4035-ae15-c09757155fd8}
Traceback (most recent call last):
  File "/home/garrett/B2G/objdir-gecko/_tests/testing/mochitest/runtestsb2g.py", line 140, in run_tests
    self.runner.start(outputTimeout=timeout)
  File "/home/garrett/B2G/../mozilla-central/testing/mozbase/mozrunner/mozrunner/remote.py", line 167, in start
    self.marionette.emulator.wait_for_homescreen(self.marionette)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/emulator.py", line 365, in wait_for_homescreen
    });""", script_timeout=120000)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 1162, in execute_async_script
    filename=os.path.basename(frame[0]))
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 613, in _send_message
    self._handle_error(response)
  File "/home/garrett/B2G/../mozilla-central/testing/marionette/client/marionette/marionette.py", line 662, in _handle_error
    raise ScriptTimeoutException(message=message, status=status, stacktrace=stacktrace)
ScriptTimeoutException: ScriptTimeoutException: timed out

Mochitest ERROR | Automation Error: Received unexpected exception while running application

Comment 17

[BMO Automation]

Firefox OS is not being worked on