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

Launching Update.exe after upgrade prompts user to locate the file #900

Closed
bsclifton opened this issue Dec 12, 2016 · 13 comments
Closed

Launching Update.exe after upgrade prompts user to locate the file #900

bsclifton opened this issue Dec 12, 2016 · 13 comments

Comments

@bsclifton
Copy link

bsclifton commented Dec 12, 2016

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

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

@bsclifton
Copy link
Author

This may be related; (output collected via logs provided by user @shlbtnk](brave/browser-laptop#6105 (comment))

2016-12-10 08:38:34> CheckForUpdateImpl: Downloading RELEASES file from https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64
2016-12-10 08:38:34> FileDownloader: Downloading url: https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64/RELEASES?id=brave&localVersion=0.12.13&arch=amd64
2016-12-10 08:38:34> FileDownloader: Downloading file: https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64/brave-0.12.14-full.nupkg
2016-12-10 08:38:50> UpdateInfo: Couldn't get release notes for:brave-0.12.14-full.nupkg: System.Exception: Invalid 'ReleaseNotes' value in nuspec file at 'C:\Users\MyPC\AppData\Local\Brave\packages\brave-0.12.14-full.nupkg'
bei Squirrel.ReleaseEntry.GetReleaseNotes(String packageDirectory)
bei Squirrel.UpdateInfo.b__19_0(ReleaseEntry x)
2016-12-10 08:38:50> Program: Starting Squirrel Updater: --update https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64
2016-12-10 08:38:50> Program: Starting update, downloading from https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64
2016-12-10 08:38:50> Program: About to update to: C:\Users\MyPC\AppData\Local\Brave
2016-12-10 08:38:50> CheckForUpdateImpl: Using existing staging user ID: //obliterated
2016-12-10 08:38:51> CheckForUpdateImpl: Downloading RELEASES file from https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64
2016-12-10 08:38:51> FileDownloader: Downloading url: https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64/RELEASES?id=brave&localVersion=0.12.13&arch=amd64
2016-12-10 08:38:51> FileDownloader: Downloading file: https://brave-download.global.ssl.fastly.net/multi-channel/releases/dev/winx64/brave-0.12.14-full.nupkg
2016-12-10 08:39:06> ApplyReleasesImpl: Writing files to app directory: C:\Users\MyPC\AppData\Local\Brave\app-0.12.14
2016-12-10 08:39:06> LogHost: Rigging execution stub for lib/net45/Brave_ExecutionStub.exe to C:\Users\MyPC\AppData\Local\Brave\Brave.exe
2016-12-10 08:39:11> LogHost: Rigging execution stub for lib/net45/resources/BraveDefaults_ExecutionStub.exe to C:\Users\MyPC\AppData\Local\Brave\app-0.12.14\BraveDefaults.exe
2016-12-10 08:39:15> ApplyReleasesImpl: Squirrel Enabled Apps: [C:\Users\MyPC\AppData\Local\Brave\app-0.12.14\Brave.exe]
2016-12-10 08:39:16> ApplyReleasesImpl: Starting fixPinnedExecutables
2016-12-10 08:39:16> ApplyReleasesImpl: Examining Pin: livestreamer-twitch-gui.lnk
2016-12-10 08:39:16> ApplyReleasesImpl: Examining Pin: Microsoft Word 2010.lnk
2016-12-10 08:39:16> ApplyReleasesImpl: Examining Pin: Windows Media Player.lnk
2016-12-10 08:39:16> ApplyReleasesImpl: Fixing up tray icons
2016-12-10 08:39:16> ApplyReleasesImpl: cleanDeadVersions: for version 0.12.14
2016-12-10 08:39:16> ApplyReleasesImpl: cleanDeadVersions: exclude folder app-0.12.13
2016-12-10 08:39:16> ApplyReleasesImpl: cleanDeadVersions: exclude folder app-0.12.14
2016-12-10 09:27:59> Program: Starting Squirrel Updater: --processStartAndWait Brave.exe
2016-12-10 09:27:59> Program: Want to launch 'C:\Users\MyPC\AppData\Local\Brave\app-0.12.14\Brave.exe'
2016-12-10 09:27:59> Program: About to wait for parent PID 5348
2016-12-10 09:27:59> Program: About to launch: 'C:\Users\MyPC\AppData\Local\Brave\app-0.12.14\Brave.exe':

Our last release (what this user should be upgrading to) is version 0.12.14 and this user has 0.12.13 locally.

@anaisbetts
Copy link
Contributor

@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 Brave.exe --squirrel-update 0.12.14.

@bsclifton
Copy link
Author

bsclifton commented Dec 13, 2016

@paulcbetts looks like we may have been broken by this commit:
electron/windows-installer@6635a83

We were pointing our packager at upstream windows-installer, which was updated from Squirrel 1.4.4 to 1.5.0. I inspected the manifest sent back, and it looked OK between versions:

old manifest

2016-12-07T21:21:12.824Z - Metadata: {
  "version":"0.12.13",
  "name":"Brave 0.12.13",
  "pub_date":"2016-12-07T17:55:25.004Z",
  "notes":"Hotfix to address URL bar usability issues and security update. More details: https://github.com/brave/browser-laptop/releases/tag/v0.12.13dev\n\nHotfix to address a security issue. More details: https://github.com/brave/browser-laptop/releases/tag/v0.12.12dev\n\nHotfix to address a security issue. More details: https://github.com/brave/browser-laptop/releases/tag/v0.12.11dev"
}

new manifest

2016-12-12T23:37:24.036Z - Metadata: {
  "version":"0.12.14",
  "name":"Brave 0.12.14",
  "pub_date":"2016-12-10T05:05:33.103Z",
  "notes":"Hotfix to address a certificate expiration issue. More details: https://github.com/brave/browser-laptop/releases/tag/v0.12.14dev"
}

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):

2016-12-07 13:21:41> ApplyReleasesImpl: Writing files to app directory: C:\Users\brian\AppData\Local\brave\app-0.12.13
2016-12-07 13:21:45> ApplyReleasesImpl: Squirrel Enabled Apps: [C:\Users\brian\AppData\Local\brave\app-0.12.13\Brave.exe,C:\Users\brian\AppData\Local\brave\app-0.12.13\Brave_ExecutionStub.exe]
2016-12-07 13:21:47> ApplyReleasesImpl: Processing shortcut 'C:\Users\brian\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Brave.lnk'
2016-12-07 13:21:47> ApplyReleasesImpl: Old shortcut target: 'C:\Users\brian\AppData\Local\brave\Update.exe'
2016-12-07 13:21:47> ApplyReleasesImpl: New shortcut target: 'C:\Users\brian\AppData\Local\brave\Update.exe'
2016-12-07 13:21:47> ApplyReleasesImpl: Old iconPath is: 'C:\Users\brian\AppData\Local\brave\app-0.12.13\Brave.exe'
2016-12-07 13:21:47> ApplyReleasesImpl: Setting iconPath to: 'C:\Users\brian\AppData\Local\brave\app-0.12.13\Brave.exe'

Updating to the new version (0.12.13 => 0.12.14)

2016-12-12 15:38:08> ApplyReleasesImpl: Writing files to app directory: C:\Users\brian\AppData\Local\brave\app-0.12.14
2016-12-12 15:38:08> LogHost: Rigging execution stub for lib/net45/Brave_ExecutionStub.exe to C:\Users\brian\AppData\Local\brave\Brave.exe
2016-12-12 15:38:14> ApplyReleasesImpl: Squirrel Enabled Apps: [C:\Users\brian\AppData\Local\brave\app-0.12.14\Brave.exe]
2016-12-12 15:38:15> ApplyReleasesImpl: Processing shortcut 'C:\Users\brian\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Brave.lnk'
2016-12-12 15:38:15> ApplyReleasesImpl: Old shortcut target: 'C:\Users\brian\AppData\Local\brave\Brave.exe'
2016-12-12 15:38:15> ApplyReleasesImpl: New shortcut target: 'C:\Users\brian\AppData\Local\brave\Brave.exe'
2016-12-12 15:38:15> ApplyReleasesImpl: Old iconPath is: 'C:\Users\brian\AppData\Local\brave\Brave.exe'

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:
C:\Users\brian\AppData\Local\brave\Brave.exe --processStart "Brave.exe"

When it launches, it opens a window immediately trying to download version 0.12.14 (saving to disk)

@bsclifton
Copy link
Author

bsclifton commented Dec 13, 2016

@paulcbetts this is probably way too much info... but I went and documented the process on our side:
https://github.com/brave/browser-laptop/wiki/How-auto-updates-for-Brave-work-on-Windows

Maybe the parts you can help me understand are:

  • What is the <%- exe %>_ExecutionStub.exe file above?

  • With Squirrel 1.4.4 => 1.5.0, did the behavior of the Update.exe file change? (it appears to have been wiped in favor of a smaller <%- exe %> executable, which caused this behavior.

@anaisbetts
Copy link
Contributor

@bsclifton Peep #868, the bug here is that we're still adding --processStart to our shortcut which is definitely bad and wrong

@bsclifton
Copy link
Author

@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 --processStart? I'll probably have to dig deeper, but I honestly don't know where it was added in the first place. Presumably, new installs (1.5.0 forward) will work fine

@anaisbetts
Copy link
Contributor

@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

@bsclifton
Copy link
Author

@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 Update.exe. We could either try to go that route OR roll forward to 1.5.0 and have the --processStart "Brave" part removed

@anaisbetts
Copy link
Contributor

anaisbetts commented Dec 13, 2016

@bsclifton The easiest way for you to solve this is to see if "processStart" is in process.argv and just ignore the whole thing. In the meantime, I'm going to have a 1.5.1 release out today that fixes this (it will also retroactively fix any borked 1.5.0 shortcuts)

@bsclifton
Copy link
Author

@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?

  1. User does fresh install of Brave using installer built with electron-winstaller 2.4.0. This creates the update.exe --processStart "Brave.exe" link on the desktop. They choose to pin it, it'll set that as the path too

  2. Instead of upgrading in app, I believe the user installed a NEW version of Brave, which was packaged with electron-winstaller 2.5.0. This installation rewrites the existing shortcuts (desktop + pinned) to use the self-named stub which is located at %USERPROFILE%\AppDir\Local\brave\brave.exe. HOWEVER, it did not remove the --processStart "Brave.exe" arguments

  3. Brave is launched. Our app is setup (thanks to the Windows shell) to accept input in a format like: %userprofile%\etc\Brave.exe -- "%1". An example of this would be like double clicking an HTML file and it opens.

  4. We have the funky logic you mentioned above to recognize the format "--*" and interpret this like it's coming from the shell, therefore opening the file.

@anaisbetts
Copy link
Contributor

Yep, that seems totally plausible

@bsclifton
Copy link
Author

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

@anaisbetts
Copy link
Contributor

@bsclifton Upgrade to 1.5.1 which not only fixes the issue, but will fix it retroactively

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

No branches or pull requests

2 participants