Menus appear blank, MacOS Mojave 10.14.6

bbrooks918
Clicking on dropdown menus produces blank windows. Also, when I first launch Zotero, the entire space is black, until I adjust the app size with my mouse or a window manager like Divvy.

I don’t recall if this coincided with a MacOS or Zotero update, but my hunch is that it was a MacOS update, since I don’t update Zotero too often.

This issue seems similar to this one (https://forums.zotero.org/discussion/73797/macos-mojave-and-zotero-dropdown-menu-problem), but I haven’t been able to resolve it. I’ve tried completely deleting Zotero and reinstalling a recent beta (Zotero-5.0.75-beta.15+da690a45b) in addition to the recent stable release (Zotero-5.0.75), but the problem persists.
  • dstillman
    Have you tried actually disabling any third-party utilities like Divvy that you're running? The issue in the other thread was both different and fixed a year ago, but there were a couple reports of this issue more recently, and switching to a new user account fixed the problem, so it's likely something that's running as your current user.
  • bbrooks918
    It does sound similar to the thread you mentioned (https://forums.zotero.org/discussion/78370/zotero-for-mac-only-black-window).

    I've tried incrementally quitting every running program, restarting Zotero between each quit, and it didn't resolve the issue. I also tried quitting a variety of background tasks via Activity Monitor and still no luck. Like the thread above, when I switch to another account, Zotero works fine.

    Have any suggestions on how to surface the rogue app interfering with the graphics?
  • bbrooks918
    I tried updating to MacOS Catalina, but no luck. Now Zotero crashes immediately so, silver lining, there is now a crash report I can send. If I send to support[at]zotero{dot}org could you have a look?

    And to be clear Zotero-5.0.76-beta.1+2bb14e5c6 and Zotero-5.0.76 both work on my test user account, so it's some rogue app or setting crashing Zotero - I just can't figure out which one.
  • dstillman
    If I send to support[at]zotero{dot}org could you have a look?
    Sure.
  • dstillman
    If you copy the contents of your Zotero profile directory to the profile directory in the new user account, does it still start up?
  • bbrooks918
    Upon copying the new user account profile directory I get this error: "Your Zotero profile cannot be loaded. It may be missing or inaccessible." If I keep both profiles in that location, I get the original error I emailed you in the crash report.
  • dstillman
    For the "missing or inaccessible" message, you just need to fix the permissions to make sure they're owned by that user account.

    I'm not sure what you mean by the second part. What do you mean by "keep both profiles in that location"? And are you saying you're now getting the crash in the new user account, which wasn't happening before?
  • bbrooks918
    Ah, I didn't change the user. My bad. So I run:
    ```
    sudo chown -R bbrooks /Users/bbrooks/Library/Application\ Support/Zotero/Profiles/5onsulx9.default/
    ```

    And I still get the "missing or inaccessible" error.

    What I meant by "keep both profiles in that location" was keeping both the old and working .default profiles in /Profiles/. I'm assuming you can't have two profiles in that directory, but was just trying it out. Currently I removed the original profile and have the profile that was copied over from the working user's account.
  • dstillman
    So just to clarify, Zotero uses the profile directory specified in the profiles.ini file in the directory one level up. So just having an extra directory in Profiles won't do anything — what matters is what's specified in profiles.ini. So the goal here is to swap in the profile directory from your initial user account but give it the name of the profile directory in the new user account, so that Zotero tries to use that folder.

    So you need to make sure that the new user account has read and write permissions for the active profile directory and all files and folders below it.
  • bbrooks918
    Still, no luck.

    I copied over the Zotero folder from the working user, "test_admin", to my broken Zotero location and changed ownership:
    ```
    sudo cp -R /Users/test_admin/Library/Application\ Support/Zotero/ /Users/bbrooks/Library/Application\ Support/Zotero/
    sudo chown -R bbrooks /Users/bbrooks/Library/Application\ Support/Zotero/
    ```

    This causes an immediate crash, similar to before, and the crash report is similar to the one I emailed you. To me, the crash report suggests Zotero is having issues accessing memory (e.g. "EXC_BAD_ACCESS (SIGSEGV)") but these crash reports are quite opaque from my perspective.
  • dstillman
    edited October 17, 2019
    That wasn't what I was suggesting, though. I was suggesting you try running the original profile directory in the new user account. You can do the same with the Zotero data directory, and if that works it confirms that there's something outside of Zotero in the original account that's breaking things. I can't really help you figure out what that is — I can just help you confirm that it's something other than Zotero and its data files.
  • bbrooks918
    It seems the issue is outside of Zotero. As you suggested, I copied the original profile to the new user, checked to see if Zotero worked (it did), and repeated for the data directory.

    I've uploaded the crash report below in case others in the future have similar issues. I'll provide an update if I figure things out on the MacOS end.

    https://drive.google.com/file/d/1VBs3nHAl11aJK_vmj4tM_qbka2fXwh6n/view?usp=sharing
  • selvaratnam
    Interesting, I'm getting exactly the same problem. My crash report is the same as yours.
  • dstillman
    @bbrooks918, @selvaratnam: I don't know if it will help, but you can try installing the latest Zotero beta, which includes some fairly major changes under the hood that might fix whatever is causing this.

    If you try it, first make a backup of zotero.sqlite in your Zotero data directory, since you won't be able to downgrade to the release version without a database backup. (The beta should make a backup automatically, but you should make one manually just to be safe.)
  • bbrooks918
    FYI, I tried 5.0.78-beta.12+88b1e10b4, with no luck. The empty menu windows persist. So far, my only solution has been to work in the newer MacOS user profile. I'll update you if I can pinpoint what, outside of Zotero, is causing the issue.
  • joeypotter3
    I had the same issue with my user profile and Dark Mode Mac OS.

    Completing these steps resolved the problem for me:

    1. Run this command in a terminal: defaults delete -g NSRequiresAquaSystemAppearance
    2. Log out and back in
    3. Go to System Preferences > General and select "Light" and then back to "Dark"
    4. Open Zotero and it should now be working as expected

    I'm running Zotero 5.0.86-beta.9+36afe4573 in macOS Catalina 10.15.4
  • dstillman
    @dawsonscott: Thanks for figuring that out. I'm curious, though — had you (or anyone else this fixes things for) previously run a defaults write command involving that flag (e.g., following instructions like these) to customize Dark Mode on a per-app basis? Or used some third-party tool that might have done so?

    It's not clear to me under what situations, if any, this would be set otherwise.
  • joeypotter3
    edited April 30, 2020
    @dstillman That's correct. I'm seeing more and more application developers force macOS Dark Mode on or off using this flag. For example, Electron's official documentation recommends when opting out to set the NSRequiresAquaSystemAppearance key in the Info.plist file to true.
  • dstillman
    But what's the answer to my question? I don't understand what's causing this flag to be set in the global domain on some people's computers (including yours).

    I can reproduce this in Zotero by setting the flag to false (in the global domain or for org.zotero.zotero), and setting it to true in Info.plist doesn't help.
  • joeypotter3
    I suspect it might be certain application developers using defaults write -g NSRequiresAquaSystemAppearance -bool Yes instead of providing their application identifier (com.microsoft.VSCode etc).
  • joeypotter3
    edited April 30, 2020
    I have a number of Electron applications I use, as well as others that might be to blame for this behaviour. I haven't run this command or any similar in my terminal, so it's the only idea I have.
  • dstillman
    Hmm, OK. They certainly shouldn’t do that. (Also, it would have to be -bool No in this case.)
  • dstillman
    Just to note here, someone in another thread had this flag set after previously using the app NightOwl on Mojave.
  • joeypotter3
    So my theory may be correct :)
  • dstillman
    No, to clarify, NightOwl was a utility specifically for auto-adjusting Dark Mode in Mojave — that's why I asked above whether you were running a third-party tool related to Dark Mode. I don't know why a non–Dark Mode related program would ever touch this flag, and it would be totally inappropriate for them to do so.
  • joeypotter3
    edited May 1, 2020
    I see. No, I haven't ever used any such third-party tools.
Sign In or Register to comment.