Closed Bug 1594131 Opened 5 years ago Closed 4 years ago

Make it a guarantee that a JSWindowActorParent's didDestroy methods will be called


(Core :: DOM: Content Processes, defect, P3)




Fission Milestone Future


(Reporter: enndeakin, Unassigned)


(Blocks 1 open bug)


I've found that willDestroy and didDestroy are often never called, making these functions mostly useless as one can't rely on them.

I note, for example of the parent side ( ) that the caller of these functions checks if various states are set and doesn't call will/didDestroy in many cases, yet the actual call to will/didDestroy doesn't seem to depend on those states.


  1. Fix them to be always be called.
  2. Make the documentation clearer as to when these will not be called and suggest alternatives.

Sorry Neil for hijacking your bug, but I think we need (reasonable) strong guarantees here, and they should be achievable.

We probably already have code in m-c that depends on these methods always firing, and even if we document the current behavior, new code is likely to land with similar assumptions.

Andrew believes this should be less of an issue without Fission, but if we're replacing code which depended on MessageManager's "message-manager-close" event reliably being called, this is not just blocking Fission, but possibly introducing bugs in current Firefox (without Fission).

My understanding here might be limited, but I don't see a reason why we couldn't ensure, whatever the reason for the child process going away, that the didDestroy() method is called for each parent actor that was linked to that process.

Neha, can you please prioritize this bug as appropriate?

Flags: needinfo?(nkochar)
Summary: Make it clearer when a JSWindowActor's willDestroy/didDestroy methods will be called → Make it a guarantee that a JSWindowActorParent's didDestroy methods will be called

This is already guaranteed. The only thing that isn't guaranteed is that willDestroy will be called.

Well both Neil and Andrew (can you please confirm?) found them not reliably called, so something is up.

Additionally, I've found that sending messages during the willDestroy callback sometimes throws, despite the comment in webidl claiming it should work. If that is a also a possibility by design, we may as well also call willDestroy right before didDestroy if we haven't had a chance to call it while it could still send messages.

Otherwise, we need to go through existing code, as willDistroy seems more popular:*.js*.js

Flags: needinfo?(nkochar) → needinfo?(continuation)

I don't remember if it was willDestroy or didDestroy that was causing issues.

Flags: needinfo?(continuation)
See Also: → 1596187

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:


Fission Milestone: --- → ?

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies)
Priority: -- → P3

Just found this while investigating:

// The 'didDestroy' callback is not always getting called.
// So we can't rely on it here. Instead, we will try to access
// the browsing context to judge wether the actor has
// been destroyed or not.

Neal, can you please provide more information here?

Flags: needinfo?(enndeakin)

My issue I think was just 1596187. I don't know what issue Abdoulaye was having.

Flags: needinfo?(enndeakin)

Future because the original problem is gone.
kmag says we may change how this code works for Fission.

Fission Milestone: ? → Future
See Also: → 1662771

didDestroy is already guaranteed to be called.
willDestroy is never guaranteed to be called. Do not use this for cleanup. Use didDestroy instead. willDestroy should be used for sending some last-minute messages, but not for cleanup.
We will fix the incorrect documentation in bug 1662771.

Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.