We already throw when it's too late to register blockers, but only when we move to the next phase. The problem I'm seeing is that when for example profile-change-teardown fires, async shutdown still allows consumers to register profile-change-teardown blockers. Thus I was wondering whether we could make addBlocker throw as soon as a phase begins and not when we move to the next phase. That means trying to register a profile-change-teardown blocker when profile-change-teardown fired will throw. To do the check we currently use _waitForMe (see comment 0), changing that check at line 693 with a check on _isStarted would implement my suggestion (we throw for new blockers of a phase as soon as that phase started), but I don't know if the original behavior was expected or even wanted.
Bug 1617559 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
We already throw when it's too late to register blockers, but only when we move to the next phase. The problem I'm seeing is that when for example profile-change-teardown fires, async shutdown still allows consumers to register profile-change-teardown blockers. Thus I was wondering whether we could make addBlocker throw as soon as a phase begins and not when we move to the next phase. That means trying to register a profile-change-teardown blocker after profile-change-teardown fired will throw. To do the check we currently use _waitForMe (see comment 0), changing that check at line 693 with a check on _isStarted would implement my suggestion (we throw for new blockers of a phase as soon as that phase started), but I don't know if the original behavior was expected or even wanted.