With Web Extension, when the targets are destroyed, their front is destroyed
before being notified to the toolbox, which makes their `actorID` being null.
We should be using a safer attribute to uniquely identify them.
Differential Revision: https://phabricator.services.mozilla.com/D220669
At the moment, the `getParent` method was using the connection `poolFor` method
to retrieve the pool that was managing it. This is quite costly as `poolFor`
loops through all the pools of the connection.
This patch adds a `parentPool` property to the Pool that is set in `manage` and
reset in `unmanage`, and used in the `getParent` method.
This speeds up getParent as well as the methods that call it (`manage` when the
actor was already managed, and `destroy`).
Differential Revision: https://phabricator.services.mozilla.com/D100981
We take this opportunity to remove Pool.get as well,
which was doing exactly the same thing as Pool.actor
This highlighted a couple issues in Reps:
- LongString were relying on the isGrip function, which was only checking that
the actor property was truthy. So it was matching LongStringFront which had
the actor method. This is modified by using the isLongString helper instead.
- The Object rep was building all the reps for the object properties, even in
TINY mode, where the result was only used to check the length. In the Accessibility
panel, it can happen that an plain object containing front properties is passed
to Rep. It was fine before because this was short-circuited by the Accessor rep
which was only checking the truthiness of a `get` property. With `get` being
removed, the default Rep was used, which is Object, and we were hitting a
recursion loop, as some of the properties of fronts are cycle references.
There should be a fix in the Accessibility panel to _not_ pass fronts, but we
also "fix" it from here by simply not building sub-properties for the object
when we're in TINY mode.
Differential Revision: https://phabricator.services.mozilla.com/D81971
This class isn't used anymore, and it's safe to remove it.
We take this as an opportunity to remove Pool#cleanup and
Pool#isEmpty, which each only had one callsite.
Some comments are updated to not mention ActorPool.
Differential Revision: https://phabricator.services.mozilla.com/D80602
Depends on D80059
removeActorPool is only called from one spot, which always passes the second optional argument as true.
Differential Revision: https://phabricator.services.mozilla.com/D80060
This is similar to what we already have in ActorPool.
We would be able to surface this information to have
a better view of our different pools.
Differential Revision: https://phabricator.services.mozilla.com/D67161
In fronts there's a parentFront property that maintain the link
between a front and its parent.
But Pool isn't using it, and retrieve the parent through poolFor,
which can be a bit slow depending the number of pools and their size.
This patch makes Fronts override the Pool#parent method to retrive the
parent from the parentFront property.
Differential Revision: https://phabricator.services.mozilla.com/D64921
Mark Banner