Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Desktop: Seamless-Updates - fixing bugs #11121

Open
wants to merge 7 commits into
base: dev
Choose a base branch
from

Conversation

AliceHincu
Copy link
Contributor

This PR fixes multiple issues:

  • locking/unlocking mechanism
    • While the new version silently downloads in the background, I locked the update process so that the user can't trigger manually another check. If the temporary new version is downloaded and then the user triggers a manual check, the temporary file is already locked by the OS so the app throws an error and closes (the user won't have permission to write to it two times at the same time). This mechanism handles this situation.
  • managing the remote process in the update service
    • The app threw an error if I set the flags to true from Options, closed the app (but not quit from the system tray), and then triggered manual checks. By making the initialization of the service not dependent on the flag, and only periodically checking for updates based on the flag, I solved this issue
  • notify if the update check is already in progress
    • If the user triggers a manual check while the periodical check downloads the update in the background, the user will now be informed that this operation is already in progress
  • notification message triggered multiple times
    • Before, if I manually checked multiple times for updates, only the first time the notification was shown. Now it can be shown multiple times. This happened because apparently the notification doesn't trigger "Dismiss" event when closing after 5 seconds.

Comment on lines 1130 to 1131
autoUpdateEnabled: { value: true, type: SettingItemType.Bool, storage: SettingStorage.File, isGlobal: true, section: 'application', public: false, appTypes: [AppType.Desktop], label: () => _('Automatically check for updates') },
'autoUpdate.includePreReleases': { value: false, type: SettingItemType.Bool, section: 'application', storage: SettingStorage.File, isGlobal: true, public: true, appTypes: [AppType.Desktop], label: () => _('Get pre-releases when checking for updates'), description: () => _('See the pre-release page for more details: %s. Restart app (quit app from system tray) to start getting them', 'https://joplinapp.org/help/about/prereleases') },
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We talked about this before - we can't have this enabled by default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flag is not the flag for my service.

https://github.com/laurent22/joplin/pull/11079/files

I set it to false in the last PR, and I switched it back to true here (like how it was before). I also hid it.

Would you like to have both flags set to false ? In this case, when the user triggers a manual check, what should happen ?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I missed you switched that off - but why did you do this? That's exactly what we did not want to happen, we talked about it and the whole reason why we have an extra feature flag for you. Now everybody who got this version will no longer be notified of new versions. I'm going to turn that back on and create another prerelease.

Comment on lines +409 to +413
bridge().electronApp().initializeAutoUpdaterService(
Logger.create('AutoUpdaterService'),
Setting.value('env') === 'dev',
Setting.value('autoUpdate.includePreReleases'),
);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise we can't have this running if the user didn't enable the feature. That's the purpose of this flag, to enable it in a controlled way. I don't really understand the logic here, why we need to run this if the flag is not on? If the user needs to restart the app after enabling the flag, we just document it. The flag is a temporary, advanced feature anyway

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

In the explanation below, by saying "default flag" I refer to the flag previously used for auto updates, together with the existing logic from before. By saying "implemented flag", I refer to the flag I added for my service.

Explanation: let's say the user has the default flag set to true and the implemented flag set to false. If he/she goes to Options to set the implemented flag to true, and then goes back into the application to manually check for an update without closing or quitting the app, the above error will be shown, because the service was never initialized in the first place (since the implemented flag was initially false).

I even tried to add this check so we could avoid this situation:
if (typeof this.updaterService_ != 'undefined' && this.updaterService_ && this.updaterService_?.checkForUpdates)
Unfortunately it still throws the error.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about the technical details, but it should be possible to turn on your feature flag and it only uses your new updater service, or turn it off and it only uses the old method. The fact that something is not working when one of the flag is on or off means some logic is missing somewhere

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants