Based on the docs true is equal to {capture: true}
> In older versions of the DOM specification, the third parameter of addEventListener() was a Boolean value indicating whether or not to use capture. Over time, it became clear that more options were needed. Rather than adding more parameters to the function (complicating things enormously when dealing with optional values), the third parameter was changed to an object that can contain various properties defining the values of options to configure the process of removing the event listener.
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#Improving_scrolling_performance_with_passive_listeners
If any package takes longer than one second (the
`saveStateDebounceInterval`) to deactivate, and the unload was triggered
by a key or mouse down, mouse event, you can end up in a situation where
sate is serialized _after_ the packages are deactivated.
The result in a bug where panes, such as the File Tree, will randomly
be closed when you reload or reopen Atom.
This can be reproduced by creating a package that has an artificially
slow `deactivate` method. With such a package enabled, every reload ends
up serializing a state where all panes are closed.
I'm a bit nervous about this exact fix, since we have to track every
place where it's possible for `prepare-to-unload` to be fired, without
the window actually closing.
I handled the only instance I saw, but the logic is complex enough, that
I'm not 100% confident there are not other instances.
If it did happen that `prepare-to-unload` was fired and some other logic
caused the window to not actually close, we could end up in a state
where mousedown/keydown events were no longer causing state to get
serialized.
