(macOS) "Hide from Dock" checkbox in settings dialog doesn't work anymore

[ernstki]

Hi everyone,

As of 6.1.0 the "Hide from Dock" checkbox in the settings dialog doesn't seem to function. You can check it, click "Save," then restart DavMail, and it's back to the unchecked state. Regardless, the app behaves like a normal Mac app, with a dock icon and a menu bar. This is a change from the 6.0.1 behavior, where this checkbox did the expected thing, and its state was preserved between invocations.

I'm struggling to understand why, because the class that I presume does this (src/java/davmail/ui/OSXInfoPlist.java) doesn't seem to have changed.

While watching the logs, I do see a stack trace with the error message Unable to update Info.plist, but I don't know which Info.plist that's trying to update. The one inside the application bundle? (Update: Yes, that one.) That would affect all users on the system, so I'm thinking that can't be right. But nothing gets written to ~/Library/Preferences/davmail.plist either, which is the place I would've expected to see that setting go, all other things being equal.

2023-07-11 21:56:09,420 WARN  [AWT-EventQueue-0] davmail.ui.OSXInfoPlist  - Unable to update Info.plist
java.io.FileNotFoundException: ../Info.plist (Read-only file system)
       at java.base/java.io.FileOutputStream.open0(Native Method)
       at java.base/java.io.FileOutputStream.open(FileOutputStream.java:298)
       at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:237)
       at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:126)
       at davmail.ui.OSXInfoPlist.setOSXHideFromDock(OSXInfoPlist.java:76)
       at davmail.ui.SettingsFrame.lambda$new$11(SettingsFrame.java:852)

Is this one of those situations where I need to grant something Full Disk Access in System Preferences? Does anybody have any other ideas, short of modifying the code and building from source? (Update: Yes, quit, move it to ~/Applications and try again.)

macOS 12.6.7 (Monterey) with openjdk 11.0.19 from MacPorts, $JAVA_HOME set to /Library/Java/JavaVirtualMachines/openjdk11/Contents/Home in my ~/.profile.

[ernstki]

If I move the app bundle to ~/Applications, it appears to work again. So I have a workaround.

Just odd that this behavior seemed to have changed since 6.0.1, but maybe I'd been using 6.0.1 since before I upgraded to Monterey (from Mojave), and DavMail hadn't needed to update this setting. Maybe the change was the OS, not DavMail.

I also finally realized that "Application is agent (UIElement)" must be the localized string for LSUIElement, which is how it appears in OSXInfoPlist.java. The answer was right in my face, in the documentation for LSUIElement.

[esabol]

@ernstki, IMHO, you should keep this issue open as this is clearly a bug that should be fixed.

Based on the ../Info.plist (Read-only file system) error message and how moving the app to your home directory fixes it, I think it's clear that it's trying to write to the .plist file inside the application bundle, to which it doesn't have write permissions. I think you are correct that it should be writing to a .plist file in ~/Library/Preferences/.

[ernstki]

@esabol I agree, in principle, but nobody else has reported this (yet?), so I'm left to assume it's something weird about my setup.

Had I the wherewithal to contribute code to write those prefs to the normal place (~/Library/Preferences), I'd want to do that, for the benefit of others. As it stands, though, I'm just happy to have a workaround.

[esabol]

@ernstki : I think no one else has reported it because there are not very many macOS users of DavMail and an even smaller percentage of those macOS users who want to hide the application from the Dock. I suggest that you reopen the issue.

[mguessan]

Thanks for your feedback.

I can just confirm that DavMail tries to update application configuration inside package.
Changing files elsewhere on the system would require more complex changes.

I no longer have a working OSX VM so at that point I can only wait for a PR or make this won't fix.

An alternative may be to use a dedicated app like: https://apps.tempel.org/PrefsEditor/