Polish the Windows upgrade experience

[bsclifton]

Steps we can take to make sure the Windows upgrade is as smooth as possible

• Ensure the name that shows in Default app settings is accurate. This gets updated during the upgrade... but doesn't always seem to be reflected. We may need to flush the MUI cache
• If a shortcut is pinned to the taskbar (before the upgrade), it needs to work after upgrade is done. It should launch into Brave Core
• @simonhong finished work on the offline installers for Windows. We should consider packaging these instead of using a stub installer. This would still need to do a silent install (ex: not escalating via UAC). The download of the Muon update will be bigger, but the install should be much quicker (especially if our CDNs experience an outage or folks are experiencing a slow connection)

[bsclifton]

The behavior for the taskbar pin is a little odd, but it DOES work 😄 (not sure why it didn't work during the demo). Basically, it launches brave-core (which has a different icon). So the pinned item never gets focus/underline (since a different executable was launched)

[bsclifton]

For the first item, I did notice the wrong name was present in the MUI cache:
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache

Deleting this key will cause it to get "re-calculated"... but even after doing that, the UI didn't update. The original key which gets set is here:
brave/browser-laptop@ff26edb#diff-ac3c512cd6ab5e2c8b8956234544a8a1R70

Somehow, the entry was removed from HKEY_CURRENT_USER\Software\Classes\Applications. I wonder if BraveDefaults.exe (which can add and remove the key) was ran during the upgrade and removed it

edit: I'm an idiot 🤦‍♂️ I never added the above change for Nightly (which is the channel I'm testing 😂 )

[bsclifton]

OK two of the items fixed above last nite 😄

@simonhong hooked me up with an offline omaha installer and I verified it works and also doesn't open the browser afterwards. He got me a copy of the one for master- I'll need one for 0.56.x on 32-bit and 64-bit cc: @mbacchi (basically blocked until we can get those

[bsclifton]

I looked at several approaches without luck. Basically, I tried creating a file master_preferences and putting it into place BEFORE the install (into the directory the brave.exe is installed into). It never gets loaded, even with a fresh profile. The contents of the master_preferences file I was using are:

{
  "distribution": {
    "do_not_launch_chrome": true
  }
}

It looks like Omaha does support passing arguments to the mini_installer.exe. I tried using the /appargs command line switch for Omaha client and it throws an error. Specifically, I was trying to pass installdata= and then the above JSON in a URL encoded format:

BraveBrowserStandaloneSetup_70_0_56_8.exe /silent /appargs "installerdata=%7B%22distribution%22%3A%20%7B%22do_not_launch_chrome%22%3A%20true%7D%7D" /install

But it appears this isn't available to Omaha client (it must be a step on the Omaha server side; perhaps when calling ApplyTag.exe)

[simonhong]

With https://github.com/brave/omaha/pull/13/files, we could migrate muon to brave silently with standalone installer.

[bsclifton]

For next steps:

• reviewers (including me) review + merge Upload windows stub/standalone installers to Github. brave-core#810
• new 0.56.x build takes place (@mbacchi can help with this)
• manually apply Add --do-not-launch-chrome to prevent launching browser at first omaha#13
• tag executable with needsadmin=False
• send @bsclifton the executable for:
  • 32 bit
  • 64 bit

Earlier today, I verified an executable @simonhong created from master using brave/omaha#13, so this approach should work great 😄

[bsclifton]

We can move forward with just 64-bit (which I confirmed works as expected!)

We'll be having a release which quickly follows 0.56.x. For that final release, we'll need to update the binaries for all platforms