cfx test in jetpack-core gets: File "resource://jetpack-core-jetpack-core-lib/page-worker.js", line 45, in const contentSymbionts = require("content-symbiont"); File "resource://jetpack-core-jetpack-core-lib/securable-module.js", line 209, in require throw new Error('Module "' + module + '" not found'); Error: Module "content-symbiont" not found and a bunch of warnings about undeclared require()s. if i try to run just the widget tests, i get: .error: unload.send() threw an exception. error: An exception occurred. Traceback (most recent call last): File "resource://jetpack-core-jetpack-core-lib/timer.js", line 60, in notify this._callback.apply(null, this._params); File "resource://jetpack-core-test-harness-lib/harness.js", line 235, in cleanup sandbox.unload(); File "resource://jetpack-core-jetpack-core-lib/cuddlefish.js", line 79, in unloadLoader this.require("unload").send(reason); File "resource://jetpack-core-jetpack-core-lib/unload.js", line 13, in send observers.forEach(function (observer) { File "resource://jetpack-core-jetpack-core-lib/unload.js", line 14, in observer(reason); File "resource://jetpack-core-jetpack-core-lib/content/worker.js", line 342, in _deconstructWorker this._port._emit('unload'); File "resource://jetpack-core-jetpack-core-lib/events.js", line 142, in _emit listener.apply(null, params); File "resource://jetpack-core-jetpack-core-lib/content/worker.js", line 235, in _destructor for (let key in publicAPI) File "resource://jetpack-core-jetpack-core-lib/es5.js", line 134, in __es5iterator__ let caller = __es5iterator__.caller; TypeError: access to strict mode caller function is censored

Me too ... http://mcepl.fedorapeople.org/tmp/cfx-testall-log.txt ... testsuite doesn't even manages to run with ebcaabe2a1aadc522477c8b97a70955a3642c7e4 (ID from github).

There was a bug report and fix done, but I failed to identify it as dependency. It also was not reviewed checked in yesterday along with other changes that I believe is causing this issue on nightly only. Can anyone in EU time zone review it so we fix it earlier? https://bugzilla.mozilla.org/show_bug.cgi?id=595980

Note: we are tracking release blockers only in bug 596524, not also this bug. Otherwise it will be too difficult to track which bugs are release blockers and thus able to land without driver approval. Case in point, bug 595980 and bug 596573 were both added as blockers to this bug by Irakli and then their fixes landed by Atul. Since this bug is a release blocker, it might have seemed as if those two bugs were also release blockers by extension and thus able to land without approval from release drivers (currently Dietrich and me). But neither of those bugs was designated as a release blocker in bug 596524, so neither bug should have landed during the freeze. To nominate a bug to block the release, post a comment to bug 596524 requesting blocking status for the bug, making sure to include a justification for requesting the status, whereupon a release driver will review the bug, make a decision about it, and update the blocking list for bug 596524 as appropriate.

All dependent bugs resolved, so tests are go.

Passing tests? I still have only 3333 of 3362 tests passed with the Mozilla binary (Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6). Which is certainly 3333 more tests passing than in the beginning of this bug, but still 29 too short.

Matej: I'm having trouble reproducing those test failures. Do they occur consistently? And is there anything about your environment that might affect these test results?

(In reply to comment #6) > Matej: I'm having trouble reproducing those test failures. Do they occur > consistently? And is there anything about your environment that might affect > these test results? Well, I don't know which particular tests fail, but the consistency is that I haven't had all tests passed since at June. This is rather normal Fedora installation with soon to be released Fedora14Beta. The only differences which can make a difference IMHO are: * firefox is in non-standard location (in my $HOME, /usr/bin/firefox is a system firefox-3.6.7-1.fc14.x86_64) * this is 64bit, which Mozilla still doesn't recognized to exist (many years after this is a norm in the Linux universe; 32bits are really dying out here) * our Python is python-2.7-8.fc14.1.x86_64 which probably is not a standard in other OSs Any ideas? BTW, mentioning Python. On every start of cfx I get: /home/matej/projekty/jetpack-sdk/python-lib/mozrunner/__init__.py:221: FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead. if desc and desc.attrib.has_key('{http://www.mozilla.org/2004/em-rdf#}id'): /home/matej/projekty/jetpack-sdk/python-lib/mozrunner/__init__.py:223: FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead. elif desc and desc.find('.//{http://www.mozilla.org/2004/em-rdf#}id') is not None:

(In reply to comment #7) > * firefox is in non-standard location (in my $HOME, /usr/bin/firefox is a > system firefox-3.6.7-1.fc14.x86_64) Hmm, that doesn't seem like it would cause problems, since other users (including myself) also test against Firefox installations in non-default locations. Another difference is that you're using Firefox 3.6.7, whereas the latest version of Firefox 3.6 (and the version with which I run Firefox 3.6 compatibility tests) is 3.6.10. I wouldn't expect that to cause problems, but I suppose it's possible. > * this is 64bit, which Mozilla still doesn't recognized to exist (many years > after this is a norm in the Linux universe; 32bits are really dying out here) I haven't tested on Linux 64bit, but I have tested on Windows 64bit, where things generally work as expected. I'm not sure what you mean about Mozilla not recognizing the existence of 64bit, but certainly the folks contributing to the Jetpack project understand that there are many users using 64bit OSes, even if we don't have good test coverage on 64bit systems yet (but then, we don't have good test coverage on 32bit systems yet either; we're still working on setting up an infrastructure for continuous integration). > * our Python is python-2.7-8.fc14.1.x86_64 which probably is not a standard in > other OSs I currently test on Python 2.6.4 on Ubuntu Linux 9.10 (32bit). I asked Atul about this, and he said he doesn't expect problems with Python 2.7, but I suppose it's also possible. > BTW, mentioning Python. On every start of cfx I get: > > /home/matej/projekty/jetpack-sdk/python-lib/mozrunner/__init__.py:221: > FutureWarning: The behavior of this method will change in future versions. Use > specific 'len(elem)' or 'elem is not None' test instead. > if desc and desc.attrib.has_key('{http://www.mozilla.org/2004/em-rdf#}id'): > /home/matej/projekty/jetpack-sdk/python-lib/mozrunner/__init__.py:223: > FutureWarning: The behavior of this method will change in future versions. Use > specific 'len(elem)' or 'elem is not None' test instead. > elif desc and desc.find('.//{http://www.mozilla.org/2004/em-rdf#}id') is not > None: I don't see that, but I assume that's because you're using a newer version of Python than I am. I have filed bug 599177 on fixing the problem. In the last day, we have fixed a couple of jetpack-core test issues that can cause cascading failures in other tests. The failures you are seeing in the jetpack-core tests might thus have been resolved. Your log also shows two testcfx failures: First, there's "ERROR: test_generate_static_docs_does_not_smoke (cuddlefish.tests.test_server.ServerTests)", for which I have filed bug 599190. Second, there's "FAIL: testBug567660 (cuddlefish.tests.test_rdf.RDFTests)", for which I have filed bug 599192.

(In reply to comment #8) > > * this is 64bit, which Mozilla still doesn't recognized to exist (many years > > after this is a norm in the Linux universe; 32bits are really dying out here) > > I'm not sure what you mean about Mozilla not recognizing the existence of > 64bit, Just a badly managed frustration with mozilla.com still not having 64bit version of Linux firefox (nor Windows ones for that matter; http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/2ed3dfbf9e224b07#). I am sorry, I should save it from a bug report.

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product. To filter bugmail related to this change, filter on the word "looptid".