Improve error handling for Studio updating process

[nightnei]

Related issues

• Fixes Error when opening the app #204

Proposed Changes

I tried to reproduce the issue, I messed up file system and I managed to reproduce the error only from inside of DMG file.
But necessary to mention:

1. I have M1 (Intel in the issue). Also, ofc, bundles are different.
2. I have macOS Sequoia 15.2 (Sierra and latter versions disallowed to update from non-Application folders)
3. I am working with Studio 1.3.3 (1.0.3 in the issue, maybe it was related to old Electron or something like that)
   Necessary to mention, that the error is thrown from Squirrel.Mac, so such issue is not specific to Studio and can be reprodicable for many different apps, so we can do not more then improving error handling.

So after different testings, I can confirm that update process work totally correctly in Studio 1.3.3 and almost latest macOS Sequoia 15.2.
What we can do (my proposed changes) - show more specific errors when it's running from inside DMG file. Also show errors to move the app to Applications folder in case if somebody accidentally encounter such error (I haven't managed to see this error) and as a last resort - show default message to check folder permissions and additionally in this case we will send Sentry error, to have move info about it, if somebody one day catch it somehow.

If this PR is merged - we can close the issue and ask the issue creator to try to reproduce it with Studio 1.3.4. So that we can catch this error in Sentry. But my assumption is that something is wrong specifically with installing Studio for that user, since during research of the error, I saw cases in some people, when just reinstalling an app fixed the issue. So I think that installing 1.3.4, after removing their version will fix it.

Testing Instructions

Apply the next diff:

diff --git a/src/updates.ts b/src/updates.ts
index 42f20a1..6a64de6 100644
--- a/src/updates.ts
+++ b/src/updates.ts
@@ -35,6 +35,7 @@ export function setupUpdates() {
        autoUpdater.setFeedURL( { url: url.toString() } );
 
        autoUpdater.on( 'checking-for-update', () => {
+               showReadOnlyVolumeError( new Error( 'Checking for update' ) );
                updaterState = 'checking-for-update';
        } );

• run npm run make

Test running Studio from inside of DMG file

• Open /out/make
• Click on Studio-1.3.3-arm64.dmg
• Open Studio from dmg, instead of dragging the app to Apllications folder
• Assert that you see the next error (ignore the fact about seeing 2 errors, it's expected from our diff above)
  

Test running Studio from Applications folder (It's literally unreal error, but it's exactly what encountered in this issue. My assumption that something is aliased/linked/etc, so with this error we will be sure, which path Studio sees)

• Open /out/make
• Click on Studio-1.3.3-arm64.dmg
• Drag to Applications folder
• Run it from there
• Assert that you see the error from diff above
  

Test running Studio outside of Applications folder

• Following previous test case, let's move Studio from Applications to Downloads (macOS Sequoia 15.2 allows to do it, unlike Sierra, so here will be used applied diff)
• Run it from Downloads
• Assert that you see the next error
  

[wojtekn]

@nightnei I'm unsure if providing the different errors adds value here. Wouldn't displaying the current dialog be enough so users who launch the app from DMG or launch it from DMG and trigger an update see this dialog? Doesn't the current dialog catch those cases? In my tests, I'm getting this dialog when I try to launch Studio from DMG:

[nightnei]

@wojtekn
While reading stackoverflow I noticed that some people by mistake, pin DMG version to dashboard and then every time they open it from dashboard. Also, there were cases when something was messed up by OS and it was thinking that it's opening from read-only volume and reinstalling an app fixed the issue.
So with changes in this PR I want:

1. Show more specific errors, so that it can help our users to understand which instanceof Studio is running (in this PR, errors contain path to the instance).
2. We don't log errors to Sentry. But in this specific issue, we had to log it, according to user's description, so I added logging errors if it happens from instances of Studio which are running not from DMG or Downloads folder.
3. Also, with proposed changes, it will be easier for us to investigate future cases, since we won't need to clarify - whether they run it from DMG or maybe Downloads folder (on earlier OS) or maybe some other place. Such granularity will definitely help us and users. And this PR doesn't add some difficult logic, so IMO it worth it.

[wojtekn]

@nightnei I see the point. Could we make the dialogs consistent with ones used during import/export errors in showErrorMessageBox, so there is a title, generic message, and then the detailed one displayed? See #765 as a reference.

For example:

Error updating Studio

Studio can only update automatically from the Applications folder. Please move Studio to Applications and try again.

Studio is running from a disk image at: PATH

Error updating Studio

Studio can only update automatically from the Applications folder. Please move Studio to Applications and try again.

Studio is running from: PATH

Error updating Studio

Studio can only update from the writable Applications folder. Please check write permissions and try again.

Studio is running from: PATH

[wojtekn]

Could we reduce responsibility by moving Sentry logging out of this function and renaming it to showReadOnlyVolumeError?

[wojtekn]

Also, I think we can merge it with showInstallLocationErrorNotice as it seems like an unnecessary abstraction now.

[nightnei]

@wojtekn, added all changes proposed by you, makes sense 👍

[wojtekn]

Thanks, looks good. Can we just improve formatting to make it consistent with push/pull error messages, what we do in showErrorMessageBox?

It's not clear at first, but dialog title should go into message prop and the content should go into detail. Also, I propose to split our current detail into two strings to make translation flow easier.

Before	After

[wojtekn]

Can we split those into two separate translatable messages?

[nightnei]

Oh, I didn't even pay attention to it, thanks Wojtek ❤️
Addressed feedback

[wojtekn]

@nightnei looks good, thanks for improving the dialog formatting.

I tested it using the DMG downloaded from the build, but it didn't catch the disk image:

[nightnei]

Hm, I tested all cases before pushing the commit and this path is very weird... Btw, looks like different errors with paths are already useful - we got some exceptional thing 🙂 Hm, I will google this path

[nightnei]

@wojtekn I haven't managed to reproduce it, but /private/var/folders is used when we run app from dmg which is "untrusted", but I can't run "untrusted" files, I must to mark them as trusted... hm, probably we have different configurations in MacOS and I don't know what exactly should I change there to get your outcome.

I updated code to address /private/var/folders, could you please do a final test?

[wojtekn]

Works fine now, thanks.