Bug 41711: Wait for the new window when doing new identity

Merge Info

Related Issues

• #41711 (closed)

Backport Timeline

• Immediate - patchsets for critical bug fixes or other major blocker (e.g. fixes for a 0-day exploit) OR patchsets with trivial changes which do not need testing (e.g. fixes for typos or fixes easily verified in a local developer build)
• Next Minor Stable Release - patchset that needs to be verified in nightly before backport
• Eventually - patchset that needs to be verified in alpha before backport
• No Backport - patchset for the next major stable

Upstream Merging

• Merge to base-browser - typically for !fixups to patches in the base-browser branch, though sometimes new patches as well
  • NOTE: if your changeset includes patches to both base-browser and tor-browser please please make separate merge requests for each part

Issue Tracking

• Link resolved issues with appropriate Release Prep issue for changelog generation

Change Description

This issue is quite interesting: some things seem to be broken when doing the new identity, but not in some user-visible way, mostly in the JS console.

I think the culprit is a race condition we have between opening the new window and closing the final old window. So, it isn't very easy to reproduce, either.

I've moved the broadcast, too, because it's intended to cleanup the things on the Tor side (the proxy nonces for domain isolation and sending the SIGNAL NEWNYM command), so nothing that actually needs to be in the middle of the Firefox cleaning.

As a side-effect, for a brief time the new window and the old window can both be seen. I hope it isn't too annoying, but I'm not sure of a way to prevent this (the paint event is what I rely on to know that the new window is ready, but the load event seemed to take longer to be dispatched).