Marionette JavascriptException: TypeError: mm is null

RESOLVED WONTFIX

Status

Firefox OS
General
RESOLVED WONTFIX
4 years ago
3 months ago

People

(Reporter: grobinson, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

4 years ago
Blocks: 858787
(Reporter)

Comment 1

4 years ago
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 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.
https://hg.mozilla.org/mozilla-central/rev/eb8002584068
Assignee: nobody → erahm
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 4

4 years ago
Was closing this a mistake? How does the linked commit resolve this issue?
Flags: needinfo?(cbook)
(Reporter)

Updated

4 years ago
Status: RESOLVED → REOPENED
Flags: needinfo?(cbook)
Resolution: FIXED → ---
(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
(Reporter)

Comment 7

4 years ago
(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).
Flags: needinfo?(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?
Flags: needinfo?(jgriffin)
(Reporter)

Comment 9

4 years ago
I'm on Linux (Mint 16 a.k.a Ubuntu 13.10) and I'm running mochitests in the emulator with "./mach mochitest-remote".
How much RAM, and are you running on an SSD?
(Reporter)

Comment 11

4 years ago
8GB, yes. (Thinkpad X1 Carbon, ~1 year old).
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.
Should we just call emulator.wait_for_homescreen() before launching the script?
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.
Flags: needinfo?(grobinson)
(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.
(Reporter)

Comment 16

4 years ago
(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
Flags: needinfo?(grobinson)
No longer blocks: 858787

Comment 17

3 months ago
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.