1565977 - Simplify destruction codepath for long-lived DevTools classes

Status: NEW

(DevTools :: General, task, P3)

Description

[Julian Descottes [:jdescottes]]

Some of our UI classes have a lifecycle linked to the toolbox, which means that they are only destroyed when the toolbox's frame is destroyed. We will call those long-lived classes

For long-lived classes, there is no need to cleanup every event listener / handler as you would for a regular short-lived class, because the document owning those listeners will be destroyed.

Therefore we could simplify the destroy codepath of long-lived classes. One of the added benefits would be to speed up the destroy, but the main added value is to try and make our destroy codepath as synchronous as possible. This would reduce races and intermittent issues we face with the toolbox destroy.

Before we start simplifying destroy methods individually we need to address some concerns:

1 - it should be easy to know if a class is a long-lived class. If a class still can be destroyed during the lifecycle of the toolbox (ie. short-lived class), we absolutely want to keep cleaning up events correctly

2 - inside a single class, if we have listeners that reach outside of the toolbox's iframe, they should be clearly identified. We will still need to remove such listeners, even on toolbox destroy

3 - we should have documentation in tree explaining how to write destroy methods correctly

It feels natural to have a sane construction/destruction pattern when writing a class, so the pattern we come up with here must limit the surprise for a newcomer to the codebase.

Some ideas that were proposed to handle this:

• use singletons for all the long-lived classes (maybe inheriting a common base class)
• provide framework helpers for attaching events. Such helpers could easily hide the complexity of removing events or not (they would just need to be aware of the fact that the toolbox is being destroyed)
• use consistent methods to add and remove listeners, with different names for document/special listeners. Eg. constructor/start/stop/destroy (see this phab comment)

Overall the idea is to propose a reusable pattern to write long-lived classes. It would be interesting to start with a panel, identify which classes fall into this category and propose a solution scoped to this panel.

Related bugs:

• destroy documentation https://bugzilla.mozilla.org/show_bug.cgi?id=1552841
• toolbox destroy https://bugzilla.mozilla.org/show_bug.cgi?id=1528976 (and blocking bugs)