macOS 1.4.0 open bounces then closes

[big610]

Is there an existing issue for this?

• I have searched the existing issues (including the closed ones)

macOS 1.4.0 bounces in the Launchpad attempting to open, then closes immediately, never opens.

Quits unexpectedly is not a Code Sign Notarization issue
I reverted back to 1.3.0 doing a sudo code sign #999 #1157.

@ahadas for your knowledge on your next build attempt, you can run the sudo command before you put it in the dmg.
You have bought an Apple ID. https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

Operating System type and version

macOS Intel

Here are some ideas to cut down your Labor.
https://github.com/pyinstaller/pyinstaller/issues/3820

[ahadas]

@big610 do I get this right that you can't start muCommander by double clicking /Applications/muCommander.app? In that case, can you please tell which version of macOS it happens on? It seems to work fine on my Intel machine and we got confirmations by several users that the app works fine on their machine, so we need more information (I'd suggest to run the process in MacOS folder within /Applications/muCommander.app, maybe that will reveal more information)

[big610]

Open bounce/Close issue confirmed on macOS 10.15.7 Catalina.
This occurrence, does not throw up a bug report & I looked thoroughly thru the Library for any error reports.
I have seen this issue happen over a dozen times with other macOS apps. Requires Developer attention.
Your suggestion won't work as an alternative, nor anything else. Thanks for your quick response, caring about your app.

[ahadas]

@big610 ah ok, that's a relatively old version so this could explain why this issue doesn't reproduce for others. can you check in the Settings -> Security & Privacy whether you see an error that comes from the Gatekeeper after failing to open muCommander?

[big610]

Nothing found there. If I can save you some labor, open to having you remote into my unit with Open Source Rust or HopToDesk. Have not had time to check Big Sur.

[pskowronek]

@big610 FYI, muC logs can be found under ~/Library/Preferences/muCommander/logs/mucommander.log (to be sure that it isn't something related to code but proper signing or sth)

[big610]

~/Library/Preferences/muCommander/logs/mucommander.log
1.1 MB for today mucommander.log
https://workupload.com/file/6uHR8tszEhV

[ahadas]

@big610 thanks for the log but it's hard to tell which version of muCommander produced it, it could be the earlier version of muCommander that started properly for you. I'd suggest to remove the log file and then try to start muCommander v1.4.0. I believe that since you didn't write that you saw the splash screen before, you wouldn't see anything in that log and then the next check would be to disable gatekeeper (with sudo spctl --master-disable)

[big610]

~/Library/Preferences/muCommander/logs/mucommander.log
Log uploaded was run on the same day I installed tested 1.4.0, re-installed 1.3.0.
Log file removed. Install 1.4.0, app continues quick Launchpad bounce attempting to open, never opens, then closes. No log created.

Opened terminal, pasted sudo xattr -cr /Applications/muCommander.
Password:
xattr: No such file: /Applications/muCommander
Same scenario, You see only in Launchpad, quick bounce fail to launch open/close. No new log created.

[PeterPlanlos]

maybe try
sudo xattr -c ~/Downloads/mucommander-1.4.0-1-x86_64.dmg
before you mount the dmg.

edit: replace ~ with the full path is maybe a good idea.

[big610]

Sudo 's have been attempted, don't & won't fix a macOS Launchpad open/closes.
This issue is related to any fail to open/then quick closes.
Search this topic example I posted originally app fails to open.
pyinstaller/pyinstaller#3820

[ahadas]

Opened terminal, pasted sudo xattr -cr /Applications/muCommander. Password: xattr: No such file: /Applications/muCommander

it should have been muCommander.app instead of muCommander

Same scenario, You see only in Launchpad, quick bounce fail to launch open/close. No new log created.

yeah, that confirms that there's an issue with triggering muCommander and not in muCommander itself
I'd bet on the Gatekeeper so I'd check if it reproduces after disabling Gatekeeper (as I commented before) but it could also be an issue with the JRE

[big610]

Gatekeeper disabled.
Proper fix: Developer Code Signs before, loading into dmg.

Security & Privacy>General:
Allow apps downloaded from: Anywhere is also enabled.
https://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/

Gatekeeper displays a nag message:

"is damaged and can’t be opened. You should move it to the Trash."
Fix: Code Sign, with sudo command.

"cannot be opened because the developer cannot be verified"
Fix: Cancel the banner. Right Click the App from Applications>Open>Open.

Triggering, not loading, failing to ever open /quick close and failing to display any nag message is related to the link I listed in 1st post.

[ahadas]

Triggering, not loading, failing to ever open /quick close and failing to display any nag message is related to the link I listed in 1st post.

you refer to pyinstaller/pyinstaller#3820, right? I didn't see anything that can be related to muCommander there, but it could be that I'm missing something - @big610 could you please check our code that creates the dmg and post the fix you have in mind?

[ahadas]

@big610 and there's this code that also signs things within the dmg that you may want to look at

[big610]

Searching macOS App's that quick open/close, that scenario is in pyinstaller/pyinstaller#3820 Is that the fix for mu? It's a clue where to begin, in searching why an app fails to open/then quick closes.
Confirming no nag message, so not Gatekeeper.

My fix for 1.3.0. I Code Signed, then put in a dmg. Then I change the date/time, to 1.3.0's to be original & true to Jul 8, 2023.
Never needs sudo command again.

this code
I would re-begin. Take 1.3.0. What's changed 1.4.0 has approximately 80 different things done. Cut down your labor process of elimination. Chose ten to begin, apply. Each time code sign, or learn how to use your paid Apple ID.
Open Source developers, & small indies, don't have the income to pay Apple. So you sign the app yourself.
I see you have 2 Apple ID's: Eclipse Foundation, Inc and one personal under your name.
If you have no cloned macOS version on a external drive, like I use. I can run see if opens. I'm open for getting available for you to remote in to my unit for faster testing process of elimination, to learn, evolve, what happened.

[ahadas]

My fix for 1.3.0. I Code Signed, then put in a dmg. Then I change the date/time, to 1.3.0's to be original & true to Jul 8, 2023.

Ah good, so could you do the same for a dmg you build from source (from the release_1_4_0 branch) and let us know the steps that work for you?

[big610]

Nobody has taught me to learn to build code from source, while I also have to many other projects that need attention.

[ahadas]

@big610 could you please try the dmg from this nightly build?

[big610]

Artifact download URL: https://github.com/mucommander/mucommander/actions/runs/9022567327/artifacts/1488950833
Same scenario, Launchpad attempts to open, never opens/quick close.

[ahadas]

Artifact download URL: https://github.com/mucommander/mucommander/actions/runs/9022567327/artifacts/1488950833 Same scenario, Launchpad attempts to open, never opens/quick close.

ack, thanks for the quick feedback

[ahadas]

@big610 did you have a chance to check v1.4.1?

[big610]

Yes I checked v1.4.1 exactly the same occurrences
as v1.4.0 . Revert back to v1.3.0 that version is fine, just deep code sign, which I did put in a dmg, so does not have to be done again.

[ahadas]

it seems like the main difference between 1.3.0 and 1.4.0/1.4.1 is that 1.3.0 was signed on my machine while 1.4.0 and 14.1 were signed on github hosted runners, I think the next step here would be to sign the nightly build on my machine like 1.3.0 was signed and see if that makes a difference

[big610]

When done with build, code sign deep, put in dmg. Code sign deep then holds for everyone.
Does not matter where the Code Sign was done. By doing it, saving, is done for everyone.
1.4.0 & forward with 1.4.1, is a different issue.

[ahadas]

When done with build, code sign deep, put in dmg. Code sign deep then holds for everyone.

yeah, that's how all those versions (1.3.0, 1.4.0 and 1.4.1) were signed - the same procedure was applied to all of them but the fact that 1.3.0 works for you while the more recent ones don't either means: (1) that there's some issue with how the procedure was implemented in github actions for 1.4.0/1.4.1; or (2) that something works differently on my machine and github hosted runners

since this issue was only reported by you and doesn't reproduce for anyone else + your machine is installed with a relatively old version of macOS, I tend to think that the issue is related to (2)

[big610]

I took your 1.3.0 code signed deep, put in dmg. Now can use over & over. When putting in another version to Applications, then to going back to 1.3.0, already CSed.

My issue with 1.4.0 & 1.4.1, they are not greyed out, they are colored-meaning workable on the unit. Silicon M Chip only shows, as greyed out. To be seeing them not greyed, supposed to run.
My older unit, not on Monterey, is not the true issue because is Applications image is colored not greyed out.
So the real issue still remains, in your process to work for Monterey, something was done wrong for older units.

To fix, the process would be take 10 changes at one, apply, Then by process of elimination work thru till found.
Your issue no older unit to test with.