In the ESR68-based Tor Browser on macOS, the App menu items are not working. For example, choosing Quit or pressing Cmd+Q has no effect. Same for Preferences and Cmd+,
A little more testing shows that About Tor Browser never works, but items like Preferences do work at first but stop after you try to access About Tor Browser. I saw the same behavior on macOS 10.14.x.
Do we get any errors in the error console? I wonder whether we made a mistake when integrating the About dialog from Torbutton directly into tor-browser.
Do we get any errors in the error console? I wonder whether we made a mistake when integrating the About dialog from Torbutton directly into tor-browser.
When I choose "About Tor Browser" from the app menu the error console shows:
A quick update: this bug occurs without any of our Tor Browser patches. Specifically, I checked out revision a37fc1d6835dcebc36ae80f1d81f06d7807988b4 and then applied the #28044 (moved) patch (e05db1ef99bf1fa0717e357d7359ab6f7104a8c6). It is easy to reproduce this bug by starting with TOR_FORCE_NET_CONFIG=1, clicking "Connect", and then hitting Cmd+, (which should open the about:preferences but does not).
Kathy and I have not found a fix for this yet, and unfortunately we will not be able to work on this ticket again until the week of September 30th. We have reached out to Mozilla for help (via tjr) but it sounds like not many people have experience with the widget/cocoa code. Here is part of what we sent to Mozilla:
We have determined the following:
The nsMenuBarX destructor is being called at some point after the Tor Launcher window closes. This causes the application menu to stop working because mMenuGroupOwner has been cleared within the MenuItemInfo objects that are associated with the Cocoa application menu items.
During construction of the nsMenuBarX object, ConstructFallbackNativeMenus() is called (it doesn't seem to be called if Tor Launcher is not opened at startup).
It would be helpful if someone could give us an overview (or in-depth?) of how the menus / menubars are expected to work on Mac. In particular these are some of our questions:
Should the nsMenuBarX destructor be called only before exiting the browser? Or is it OK that it is called while a browser window is open?
Should ConstructFallbackNativeMenus() be getting called at startup?
After a lot of debugging, Kathy and I learned two things:
The menu-related code in widget/cocoa is fragile and does not recover well when things occur in a different order than in Firefox.
The root cause of this bug is that the browser's hidden window is created earlier than usual when Tor Launcher is present, and later during browser startup that hidden window is replaced with a new one. Some of the app menu data structures are associated with the first hidden window and they are freed when that hidden window is freed which breaks the app menu functionality.
We found two possible ways to fix this bug:
(a) Change Tor Launcher to open its wizard/progress window later during the startup sequence.
(b) Change the hidden window creation code inside the guts of the browser to not re-create the window.
Kathy and I believe option (b) is a safer fix. We will post both patches so other people can take a look.
The risk is that this significantly changes the point in time at which Tor Launcher blocks browser startup with its modal window, and it is difficult to analyze everything that happens between profile-after-change and final-ui-startup.