Provide a callback for creation/destruction of JSContexts

RESOLVED DUPLICATE of bug 342737

Status

()

Core
JavaScript Engine
--
enhancement
RESOLVED DUPLICATE of bug 342737
15 years ago
10 years ago

People

(Reporter: David Bradley, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
We could streamline and make XPConnect's code much simpler if there was a
callback provided that was called when a JSContext is created or destroyed.
Right now, XPConnect has to go through and match up its contexts with the
JSContexts and cleanup them up.

Currently XPConnect relies on clients to call XPConnect on new contexts, and
generates a assertion if that's not done. This is so it can place the
"Components" property on the global object. This could happen automatically with
such a callback.

Comment 1

15 years ago
Reassigning; cc'ing Brendan on this request -
Assignee: rogerl → khanson
Not all contexts created in a runtime would want the Components object, though
-- how would you know which ones to skip?

/be
(Reporter)

Comment 3

15 years ago
I wasn't sure how often JSContexts were created that would never be used by
XPConnect. A notification on destruction would be beneficial. Either a global
callback, or a callback provided when the context was created. This would still
make life a lot simpler for XPConnect, and eliminate much of the sync context
code that we have now. I doubt it would be much of a code size win, but it would
simplify and eliminate the need for most if not all of the sync context code
that exists in XPConnect.

Updated

12 years ago
Assignee: khanson → general
QA Contact: pschwartau → general

Comment 4

11 years ago
This was implemented in bug 342737, wasn't it?

Comment 5

11 years ago
(In reply to comment #4)
> This was implemented in bug 342737, wasn't it?

Yes.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 342737
(Reporter)

Comment 6

10 years ago
Should this bug really be duped? This bug was more about streamlining xpconnect's context logic. The callbacks were just one way of doing that. Given that we now have the callbacks there's work that could be done to XPConnect to change the way XPConnect sync's the contexts. It might prove to be a nice little perf win.

Comment 7

10 years ago
> Given
> that we now have the callbacks there's work that could be done to XPConnect to
> change the way XPConnect sync's the contexts. It might prove to be a nice
> little perf win.

See bug 408539. It may not be a performance win, but at least it simplifies code a lot.

You need to log in before you can comment on or make changes to this bug.