2.4: Brave Epichrome app instance not loading settings
ylluminate opened this issue · 15 comments
I'm having a strange issue with one of my Epichrome App Brave browsers. Recently, I updated the browser to 2.4.0. It worked well for a day or two, but now I'm suddenly getting a vanilla Brave window whenever I startup the browser. I have no bookmarks, history, extensions, nothing. Totally empty.
What's weird is that when I went into the ~/Library/Application Support/Epichrome/Apps/MyBrowser folder, I noticed that the data for the browser is still there. I can still see my History file, plus my extensions, and other settings. But I have no idea why I'm getting an empty browser even though all the data is there. I tried looking under the Logs folder and I'm not seeing any errors in there. Is there another location I can look in to get a clue about what's going on? Where are logs in 2.4?
I tried to execute the app from the shell, but there doesn't appear to be much useful info as to why the settings aren't loading:
$ /Applications/Epichrome/MyBrowser.app/Contents/MacOS/Brave\ Browser
GVA encoder info: AMD performance mode : 2
GVA encoder info: deleteSCDMetalContext : texture cache hits: 0, misses: 0
UpdateRecents: about to call HIS_XPC_GetApplicationPolicyForURLs with seed 251599062
UpdateRecents: received results from HIS_XPC_GetApplicationPolicyForURLs
UpdateRecents: ignoring results because menu isn't open
[54143:775:0325/144339.049369:ERROR:device_event_log_impl.cc(214)] [14:43:39.049] FIDO: touch_id_context.mm:127 Touch ID authenticator unavailable because keychain-access-group entitlement is missing or incorrect
[54143:775:0325/144341.288289:ERROR:CONSOLE(0)] "Unchecked runtime.lastError: The message port closed before a response was received.", source: chrome://newtab/ (0)
Take a look at the app bundle. Is it very large? Like close to 500MB? If so, you likely had a crash and it got left activated. Simplest solution is to make sure it's not running, then run the new Epichrome Scan.app. That should clear it right up.
If that's not it, let me know and we'll keep diagnosing. Logs for 2.4 are in the same place as 2.3 (~/Library/Application Support/Epichrome/Apps/<AppID>/Logs), so if you're not seeing logs for the most recent runs, it likely supports the theory that you're trying to launch an active engine.
Did as you suggested and ran Epichrome Scan.app which DID indeed restore the Epichrome Brave app in question. Oddly I'm not aware of any crash of the app that may have caused it. I know for sure that the computer did not crash, so something strange did happen... I guess the exercise is now left to figure out what may have provoked this and watch for it in the future.
Is there a chance to have Epichrome Apps (Both Chrome & Brave) run some test at their start that initiates the Scan function as a sanity check vs running the app to check them all separately?
Yeah, in all my testing it's been very reliable in cleaning up after itself unless there's a system crash, and I've had very few bug reports from others that weren't connected to some kind of crash. If it happens regularly on your system, it might be worth keeping an eye on it to see if you can discern what could be causing it.
As for having apps run a check at startup, there's no way to do that with the new 2.4 architecture, because the engine gets swapped into the app itself. That's why I created Epichrome Scan.app and the login scanner. If an app doesn't clean up after its run, the original app can't be run because it's not actually there. It's the one drawback of the new architecture (which is much cleaner and better in all other ways), but I put a lot of work into making sure the cleanup process was very reliable and stable, so if it's for some reason failing regularly on your system, I really want to find out why. Please keep me posted!
Now that you've confirmed this is what's going on, lets move this discussion to issue #202.
Duplicate of #202
I guess my thought is thus: is it possible to add (touch) a flag on the filesystem that remains in place following a crash? One app startup the script would test for the existence of this and if exists then it will repair itself prior to start. This could eliminate the need for the scan procedure, which can be lengthy for many Epichrome apps.
Otherwise, yes, I'll report any results I observe in the other ticket.
It's a little hard to describe why, but there's no test I can have the app do on startup, because if the app has been left activated, it is literally not the app any more, it's just the underlying browser engine with different icons. That's why when you run it, it opens a generic browser with all your sessions gone--it thinks it's the real Chrome or Brave.
In the long run there may be some kind of monitor process I could leave running, but I hate to have Epichrome leave extra processes running all the time, and (aside from yours) these kinds of reports seem to always be connected with rare events like system crashes...
Hmm, I'm having a very hard time coming to grips with why a filesystem based flag file could not fulfill the necessary role here in if set at start since it would remain in the app's folder through execution and even remain upon a crash, whereas with a successful exit it could be removed. I thought that an Epichrome script remained running during a browser's lifetime in some fashion for each Epi-app, especially since a bash instance seems to be spawned by each Epi-app...
Yes, the launch script remains running during the browser's lifetime, and as soon as the browser quits, that launch script is supposed to clean it up and put itself back into the app bundle. But if it crashes before the browser (as must be what's happened on your system), then it can't do that. Thus the next time you try to run the app, the launch script does not run. A filesystem-based flag wouldn't help this situation because when an app is left in a bad state, you're not actually running your app, just the browser.
Just wanted to say thanks for pointing me to the scan app - very helpful in resurrecting my installs post upgrade. If other folks are having trouble where apps aren't behaving separately as nice little sandboxes, running /Applications/Epichrome/Epichrome\ Scan.app worked for me.
FYI: I am consistently running into these instances where Scan has to be executed essentially 1-3 times a day at this point with Epichrome apps being corrupted. No machine crashes, just keeps happening. The worst thing going on is that there's no seeming rhyme or reason as to when this happens since I'm just quitting Epi'apps and sometimes there's a problem and sometimes there's not.
Interesting observation: so far I've been able to reproduce the application I'm reporting in this ticket (#303) restarting without retaining its settings and a Scan needing to be run on it each time. This of course is one of the apps that does not retain passwords now either.
The logs (with debug enabled) before and after running Scan to execute this problem app:
Before:
*[34381]APPNAME(477)/checkenginepayload(2415): Engine payload not found.
*[34381]APPNAME(481): Replacing damaged or missing engine.
After:
[42080]APPNAME(2208): Core 2.4.2 initialized in app APPNAME.
[42080]APPNAME(138)/readconfig(2756): SSBAppPath='/Applications/Epichrome/Apps/APPNAME.app'
[42080]APPNAME(138)/readconfig(2756): SSBLastRunVersion='2.4.2'
[42080]APPNAME(138)/readconfig(2756): SSBLastRunEngineType='external|com.google.Chrome'
[42080]APPNAME(138)/readconfig(2756): SSBLastRunEdited=''
[42080]APPNAME(138)/readconfig(2750): SSBUpdateIgnoreVersions=( )
[42080]APPNAME(138)/readconfig(2756): SSBPayloadPath='/Applications/Epichrome/Payload.noindex/gplymale/APPNAME'
[42080]APPNAME(138)/readconfig(2756): SSBLastErrorGithubFatal=''
[42080]APPNAME(138)/readconfig(2756): SSBLastErrorNMHInstall=''
[42080]APPNAME(138)/readconfig(2756): SSBLastErrorFailsafe=''
[42080]APPNAME(138)/readconfig(2750): SSBEngineSourceInfo=( com.google.Chrome Google Chrome Chrome Google Chrome 87.0.4280.141 app.icns document.icns /Applications/Google Chrome.app Google/Chrome Google Chrome Master Preferences --enable-features=PasswordImport )
[42080]APPNAME(226)/getepichromeinfo(261): Found Epichrome 2.4.2 at '/Applications/Epichrome/Epichrome.app'.
[42080]APPNAME(226)/getepichromeinfo(340): Current version of Epichrome (2.4.2) found at '/Applications/Epichrome/Epichrome.app'
[42080]APPNAME(237)/checkappupdate(377): No newer version found.
[42080]APPNAME(256)/checkgithubupdate(680): Not yet due for GitHub update check.
[42080]APPNAME(348)/getextenginesrcinfo(2126): Trying path '/Applications/Google Chrome.app'...
[42080]APPNAME(348)/getextenginesrcinfo(2187): External engine Google Chrome 87.0.4280.141 found at '/Applications/Google Chrome.app'.
*[42080]APPNAME(477)/checkenginepayload(2415): Engine payload not found.
*[42080]APPNAME(481): Replacing damaged or missing engine.
[42256]APPNAME|payload(2208): Core 2.4.2 initialized in app APPNAME.
[42256]APPNAME|payload(99): Creating external Chrome engine payload in '/Applications/Epichrome/Payload.noindex/gplymale/APPNAME'.
[42080]APPNAME(534)/setenginestate(2487): Engine activated.
[42080]APPNAME(545)/launchapp(2909): Launched engine with PID 42926.
[42080]APPNAME(585)/writeconfig(2835): Configuration variables have not changed. No need to update.
[42080]APPNAME(674): Waiting for engine to quit...
I've continued to have this problem more and more. It seems to be becoming repeatable without any actual log entries. I've given up at this point on actual Chrome instances of Epichrome and moving entirely to Brave. Brave restores username/password saving functionality for each browser that I edit to use Brave instead. This is unfortunate since a couple of my browsers actually need to be Chrome proper, but such is life at present...
I really suspect something on your system is interfering with the main launcher/monitor processes, which are what restore an app after it quits. Can you think of any nonstandard core Unix tools or anything you might have installed in the default paths? (For example, if Epichrome was somehow using the wrong version of bash that could certainly cause unpredictable behavior.)
Not that I can think of. bash is standard (I use zsh and also fish sometimes). Other GNU tools are prefixed with g. Can I get a list of all shell tools that are used and I'll pull out the path and version info for each of them to see if perhaps there is something I'm not aware of going on?
At present, here are all the tools being invoked in Epichrome and its apps:
/bin/bash
/bin/cat
/bin/chmod
/bin/cp
/bin/date
/bin/ln
/bin/ls
/bin/mkdir
/bin/mv
/bin/pax
/bin/rm
/bin/rmdir
/bin/sleep
/usr/bin/curl
/usr/bin/find
/usr/bin/iconutil
/usr/bin/mdfind
/usr/bin/mkfifo
/usr/bin/mktemp
/usr/bin/open
/usr/bin/osascript
/usr/bin/perl
/usr/bin/pgrep
/usr/bin/php
/usr/bin/plutil
/usr/bin/python2.7
/usr/bin/sed
/usr/bin/sips
/usr/bin/sort
/usr/bin/stat
/usr/bin/tar
/usr/bin/touch
/usr/libexec/PlistBuddy
Thank you for sharing this list. Things have remained a bit over the top work wise, but the only differential I found here is that while /usr/bin/python2.7 ⇒ ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 exists, my PATH first exposes /opt/local/bin/python2.7. Otherwise the others are all default first in PATH except for the /usr/libexec/PlistBuddy of course.