(In reply to :Felipe Gomes (needinfo me!) from comment #6)
So this happens because the hidden window getter now triggers the creation of the hidden window , and there's some code that is running that is triggering it (probably nsCocoaUtils::GetHiddenWindowWidget()  called by the nsMenuBar code).
Previously, for a profile manager run, the CreateHiddenWindow call inside XREMain::XRE_mainRun() would never be reached, so the getter would just return null and the profile manager wouldn't initialize the hidden window from the menu bar code.
We had to add a similar fix for calls to GetHiddenWindow from process that are not the parent process . Mossop: Is there a simple a simple way to detect "this is a profile manager run, and not the full browser starting up"? (to be called from )
Not specifically (though we could add one) but there are two ways I can think of that identify this as early in startup:
nsIAppStartup.startingUp will return true early in startup. That changes to false here which is pretty close to where the hidden window was created previously. Might cause issues for any UI opened from final-ui-startup. I can't spot any with a quick skim though.
Just try and get ProfD from the directory service, if it fails then you're in early startup (changes here: https://searchfox.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#4135). I'm guessing the errors we're seeing are exactly because ProfD is not set yet so maybe that is the most accurate check?