Closed Bug 1691081 Opened 3 years ago Closed 1 year ago

Consumers of the RemoteAgent component have to create an instance and not import it via a chrome:// URI

Categories

(Remote Protocol :: Agent, defect, P3)

Product:
Remote Protocol
Component:
Agent
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: whimboo, Unassigned)

References

Details

Consumers of the Remote Agent currently include the RemoteAgent.jsm directly instead of creating an instance of the XPCOM interface:

https://searchfox.org/mozilla-central/rev/40205f1b55f1ba8a26fcbd362c20d843e8718a87/toolkit/modules/Troubleshoot.jsm#956

We should update all these instances, which also include our browser chrome tests.

This blocks bug 1690468.

Summary: Consumers of the RemoteAgent interface have to create an instance and not import it via a chrome:// URI → Consumers of the RemoteAgent componeent have to create an instance and not import it via a chrome:// URI
Summary: Consumers of the RemoteAgent componeent have to create an instance and not import it via a chrome:// URI → Consumers of the RemoteAgent component have to create an instance and not import it via a chrome:// URI

To get this working we would actually have to change listen() and close() to return a Promise (bug 1675471), or make them synchronous. The work here exceeds the planned time for refactoring. As such we will keep the imports as they are for now.

No longer blocks: 1690252, 1690468
Depends on: 1675471
Assignee: hskupin → nobody
Status: ASSIGNED → NEW
Priority: P2 → P3
Whiteboard: [bidi-m1-mvp]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #0)

Consumers of the Remote Agent currently include the RemoteAgent.jsm directly instead of creating an instance of the XPCOM interface:
https://searchfox.org/mozilla-central/rev/40205f1b55f1ba8a26fcbd362c20d843e8718a87/toolkit/modules/Troubleshoot.jsm#956

Not sure if that is really something that we should do. Using the interface certainly adds a probably non-neglectable performance overhead compared to just loading the ESM module. I would tend to say that we should close this bug as wontfix.

Gijs, would you have some feedback for us? How is that done in general for other JS components in Firefox that also have an XPCOM interface? Thanks!

Flags: needinfo?(gijskruitbosch+bugs)

Wontfixing this seems reasonable to me. I'm not sure there's really a big overhead - none of the crossing of the XPCOM boundary would be hot code for this module, I think?, and perhaps we optimize js-to-js interface use anyway, but I also don't see much downside in keeping the code the way it is now.

Flags: needinfo?(gijskruitbosch+bugs)

Sounds good. Thanks!

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.