Closed Bug 1761072 Opened 3 years ago Closed 3 years ago

Unable to debug xpcshell-tests involving add-on manager (Error: Duplicate BroadcastConduit method name recvPortConnect)

Categories

(WebExtensions :: Developer Tools, defect, P1)

defect

Tracking

(firefox-esr91 unaffected, firefox98 unaffected, firefox99 unaffected, firefox100 fixed)

RESOLVED FIXED
100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- unaffected
firefox99 --- unaffected
firefox100 --- fixed

People

(Reporter: standard8, Assigned: robwu)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [addons-jira])

Attachments

(1 file)

What were you doing?

  1. Run an xpcshell-test which has the add-on manager enabled and enable the jsdebugger, e.g.

./mach xpcshell-test toolkit/components/search/tests/xpcshell/test_webextensions_install.js --jsdebugger

  1. Via about:debugging, inspect the xpcshell-test process.
  2. Press "Run" in the debugger

What happened?

Test fails with:

ERROR Unexpected exception Error: Duplicate BroadcastConduit method name recvPortConnect at resource://gre/modules/ConduitsParent.jsm:98
openConduit@resource://gre/modules/ConduitsParent.jsm:98:15
BroadcastConduit@resource://gre/modules/ConduitsParent.jsm:268:9
init@resource://gre/modules/ExtensionParent.jsm:268:20
@resource://gre/modules/ExtensionParent.jsm:402:16
@resource://gre/modules/Extension.jsm:83:41
promiseStartupManager@resource://testing-common/AddonTestUtils.jsm:774:5
setup@/Users/mark/dev/gecko/objdir-ff-opt/_tests/xpcshell/toolkit/components/search/tests/xpcshell/test_webextensions_install.js:26:9
async*_run_next_test/<@/Users/mark/dev/gecko/testing/xpcshell/head.js:1772:22
_run_next_test@/Users/mark/dev/gecko/testing/xpcshell/head.js:1772:38
run@/Users/mark/dev/gecko/testing/xpcshell/head.js:818:9
_do_main@/Users/mark/dev/gecko/testing/xpcshell/head.js:240:6
_execute_test@/Users/mark/dev/gecko/testing/xpcshell/head.js:603:5
@-e:1:1

What should have happened?

Test should have run & passed.

Anything else we should know?

Tested with the latest mozilla-central & nightly builds.

The tests start up the add-on manager, and it seems to be this that is causing a conflict.

to investigate

Flags: needinfo?(jdescottes)

We have two stack trace leading to call openConduit for this method:

BroadcastConduit@resource://gre/modules/ConduitsParent.jsm:271:9
init@resource://gre/modules/ExtensionParent.jsm:268:20
@resource://gre/modules/ExtensionParent.jsm:402:16
defineLazyModuleGetter/<@resource://devtools/shared/loader/builtin-modules.js:165:26
get@resource://devtools/shared/loader/builtin-modules.js:118:28
watch@resource://devtools/server/actors/resources/extensions-backgroundscript-status.js:44:5
watchResources@resource://devtools/server/actors/resources/index.js:288:19
watchResources@resource://devtools/server/actors/root.js:562:21
handler@resource://devtools/shared/protocol/Actor.js:175:37
onPacket@resource://devtools/server/devtools-server-connection.js:379:58
_onJSONObjectReady/<@resource://devtools/shared/transport/transport.js:464:22
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22
_initDebugging@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:495:6
_execute_test@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:546:21

and

openConduit@resource://gre/modules/ConduitsParent.jsm:97:21
BroadcastConduit@resource://gre/modules/ConduitsParent.jsm:271:9
init@resource://gre/modules/ExtensionParent.jsm:268:20
@resource://gre/modules/ExtensionParent.jsm:402:16
@resource://gre/modules/Extension.jsm:83:41
promiseStartupManager@resource://testing-common/AddonTestUtils.jsm:774:5
setup@/Users/jdescottes/Development/hg/fx-team-artifact/objdir.noindex/_tests/xpcshell/toolkit/components/search/tests/xpcshell/test_webextensions_install.js:26:9
async*_run_next_test/<@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:1772:22
_run_next_test@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:1772:38
run@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:818:9
_do_main@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:240:6
_execute_test@/Users/jdescottes/Development/hg/fx-team-artifact/testing/xpcshell/head.js:603:5

Meaning this is a regression from Bug 1748529

Luca: do you have any suggestion on how we should handle this?

Flags: needinfo?(jdescottes) → needinfo?(lgreco)
Regressed by: 1748529
Severity: -- → S3
Priority: -- → P2

Set release status flags based on info from the regressing bug 1748529

ExtensionParent.jsm is loaded twice, because the ChromeUtils.import call in the devtoools module loads a new instance of the file in the devtools samdbox at https://searchfox.org/mozilla-central/rev/be4604e4be8c71b3c1dbff2398a5b05f15411673/devtools/shared/loader/builtin-modules.js#44

ExtensionParent is referenced at
https://searchfox.org/mozilla-central/rev/be4604e4be8c71b3c1dbff2398a5b05f15411673/devtools/server/actors/resources/extensions-backgroundscript-status.js#9

Assignee: nobody → rob
Status: NEW → ASSIGNED
Priority: P2 → P1

So ExtensionParent.jsm is loaded again the second time because there is a failure at the first attempt. Consequently, the start of ExtensionParent.jsm runs twice.

The error at the first run is as follows:

Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]

at resource://gre/modules/ExtensionParent.jsm:1913:21, i.e. the call to Services.dirsvc.get("ProfLD", Ci.nsIFile) at https://searchfox.org/mozilla-central/rev/0077f2248712a1b45bf02f0f866449f663538164/toolkit/components/extensions/ExtensionParent.jsm#1911

There are two ways to fix it:

  1. Is to make StartupCache.file a lazy getter so that Services.dirsvc.get is called later. I confirmed that this works.
  2. is to figure out why Services.dirsvc.get fails, and to see if we need to initialize dirsvc earlier or look for alternatives.
Has Regression Range: --- → yes

ExtensionParent.jsm cannot be loaded without a profile, as explained at
https://bugzilla.mozilla.org/show_bug.cgi?id=1761072#c5.

But ExtensionsBackgroundScriptStatusWatcher would try to (lazily) load
the module before a profile was ready, in order to subscribe to future
changes. To avoid loading this whole ExtensionParent.jsm module, I have
replaced the event propagation mechanism with observers.

Whiteboard: [addons-jira]
Flags: needinfo?(lgreco)
Component: Debugger → Developer Tools
Product: DevTools → WebExtensions
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/d256dd748a15 Replace use of ExtensionParent in devtools' ExtensionsBackgroundScriptStatusWatcher r=rpl,jdescottes
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: