-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Launching Update.exe after upgrade prompts user to locate the file #900
Comments
This may be related; (output collected via logs provided by user @shlbtnk](brave/browser-laptop#6105 (comment))
Our last release (what this user should be upgrading to) is version 0.12.14 and this user has 0.12.13 locally. |
@bsclifton This all looks correct, I think Brave is doing something silly. The good news is, testing squirrel hooks is super easy, just copy in your code to app-0.12.14 then run |
@paulcbetts looks like we may have been broken by this commit: We were pointing our packager at upstream old manifest
new manifest
When the update process ran though, I can see different results updating from n-2 to the n-1 (0.12.12 => 0.12.13):
Updating to the new version (0.12.13 => 0.12.14)
Notice that the new version doesn't modify Update.exe anymore; it updates Brave.exe. So the user ends up with a shortcut that has this for the target: When it launches, it opens a window immediately trying to download version 0.12.14 (saving to disk) |
@paulcbetts this is probably way too much info... but I went and documented the process on our side: Maybe the parts you can help me understand are:
|
@bsclifton Peep #868, the bug here is that we're still adding --processStart to our shortcut which is definitely bad and wrong |
@paulcbetts gotcha- so this functionality was deprecated between 1.4.4 and 1.5.0 (per changes in #868) I'm curious: why didn't Squirrel remove the |
@bsclifton We moved to a new method but the old one still works, it's not a breaking change. We're just incorrectly appending the --processStart parameter |
@paulcbetts ah- Is there an elegant way to repair these shortcuts? If I revert back to the older version of Squirrel, it doesn't redo the shortcuts with |
@bsclifton The easiest way for you to solve this is to see if "processStart" is in |
@paulcbetts we've been able to reproduce this several times, but there don't seem to be definitive steps. Can you help me understand a given scenario?
|
Yep, that seems totally plausible |
I think we can close this issue, but I'd like to verify the above is expected behavior (the links having their executable names changed, but not the arguments). Intentional or not, we'll have to work around that, but we're tracking that on our side |
@bsclifton Upgrade to 1.5.1 which not only fixes the issue, but will fix it retroactively |
We use Squirrel for the Windows version of our browser, Brave. It looks like we were using version 1.4.4 (through electron-windows-installer)
We've been receiving reports recently from folks who are being prompted to locate the executable after an upgrade happens. Here's an example screenshot, courtesy of our user @privatzee
![image](https://cloud.githubusercontent.com/assets/22591438/21113600/3a98f598-c078-11e6-9154-c7189ed8ab5c.png)
Our installs typically go to
%USERPROFILE%\AppDir\Local\brave
, as shown above. The update.exe goes there and then updates go into sub-folders. In this instance, it can't find the executable because the 0.12.14 folder doesn't exist, but they have a previous version of Brave.We have more user reports located here: brave/browser-laptop#6075
cc: @paulcbetts
The text was updated successfully, but these errors were encountered: