2.4 update: session retention not reliable
ylluminate opened this issue · 16 comments
When updating to 2.4.0 I've found that sometimes tabs (sessions) are retained... and sometimes they're not. Not sure of the rhyme or reason thereof as of yet, but thought I should note the issue.
Oddly also passwords were wiped out.
When updating to 2.4.0 I've found that sometimes tabs (sessions) are retained... and sometimes they're not. Not sure of the rhyme or reason thereof as of yet, but thought I should note the issue.
I hade twice this experience today but not sure what happened exactly. Will try to reproduce it
Also I experienced a list of icon and after editing the app my user data was lost. Also I will try to reproduce it and report
The plot thickens for me: I noticed that beyond simply not retaining sessions and passwords the Epichrome app instance will not even offer to save passwords now. I've quit and restarted, but password retention no longer works (although sessions are retained between restarts AFTER the update failure).
Hmm. This feels like a return to a very old problem in the early 2.3.0 betas where some folks had problems getting their apps to retain password information due to the app not properly interacting with the system keychain. I thought that had gotten resolved when I started signing the Brave executable.
I guess the first question: are all the apps experiencing this problem Brave-based? If you're seeing this with Chrome-based apps too, then I truly have no idea what's going on. Meantime, it could be worth trying this process from the Troubleshooting guide: Login data not saving (be sure to back up any saved passwords from all your Brave apps first, as doing this process will lose them).
If either of you find any pattern to why some apps are doing this an others are not, please let me know. Any information could help track it down.
Wow - just had a horrible experience here. One browser that successfully updated and was already a Brave browser and had already run successfully before has lost all session info, all settings, and all extensions.
As for your last question:
are all the apps experiencing this problem Brave-based?
The answer is: No. They have been straight Google Chrome browsers that have exhibited this.
As for the new experience of losing everything in Brave, I'm attempting to figure out what's going on since the old Brave settings seem to be intact, but I'm having some trouble figuring out why Brave would not load them. I've generated a new ticket: #304
Passwords continue to not able to be saved at this point. FYI, even though the release notes didn't make any mention, 2.4.1 doesn't help on this front either.
So to double-check, these are Chrome-based apps that you've confirmed were not left active (you've run Epichrome Scan before launching)? I can't think of why you wouldn't be able to save passwords in that situation as those apps are literally unaltered, signed versions of Chrome, and should just use the Chrome keychain item...
Yes, Chrome apps. Epichrome Scan detects no incongruities for this (it's a particular Epi-Chrome-app at present). I hear you completely and I am likewise baffled. Extensions load, settings even seem to be retained in this one... but it no longer will save or fill passwords (although, crazily, it does save the username).
Also, of note, all logs (in Library/Application Support/Epichrome/Apps/MyEpiChromeApp/Logs) for this particular app are from December, so they are all pre 2.4.x release.
Stop the presses - something wild has happened. After something like the 15-20th run of this particular browser now, and around 3 times running after the 2.4.1 update, passwords are now saving again. THE OLD PASSWORDS ARE ALSO AVAILABLE AGAIN Important to note is that Epichrome Scan did NOT report any changes to this EpiChromeApp. It has only fixed another EpiBraveApp that I before reported and another EpiChromeApp that was NOT this app... I'm thoroughly confused and somewhat concerned. Logs are still not being generated, so that bugs me too...............
Well, hmm. I guess this is good in the sense that it's working again, and nothing was lost.
With release versions of Epichrome, logs generally aren't generated unless something goes wrong. Debug messages are turned off by default. You can turn them on for a run by launching from the command-line with:
<YourApp.app>/Contents/MacOS/Epichrome --epichrome-debug
Unfortunately another EpiChrome (NOT BRAVE) app I updated today exhibited this same previous behavior. No saved session + missing passwords. Extensions retained and SessionBuddy saved the day in that sessions missing aspect, but passwords not restoring yet after multiple restarts.... Nothing in Logs folder either.
Have you run that app with --epichrome-debug turned on? If there's no errors showing up even with that, then this truly feels like gremlins to me. Do any of these apps have hard-wired app window or browser-tab URLs or are they all set up with no URLs? If the latter, I wonder if that somehow has something to do with this...?
So I continue to experience this sporadically and now again consistently with the app I initially had trouble with and also now another EpiChrome (not Brave) instance on another system that was updated wherein passwords are no longer filled. I even turned on the Google account sync to restore passwords on one of them and that also likewise did not facilitate the population of passwords.
I ran it with the --epichrome-debug argument (both via:
/Applications/Epichrome/Apps/MYAPPNAME.app/Contents/MacOS/Google\ Chrome --epichrome-debugandopen "/Applications/Epichrome/Apps/MYAPPNAME.app" --args --epichrome-debug)
and don't see anything indicative of a problem in the log:
[4150]MYAPPNAME(2208): Core 2.4.2 initialized in app MYAPPNAME.
[4150]MYAPPNAME(138)/readconfig(2756): SSBAppPath='/Applications/Epichrome/Apps/MYAPPNAME.app'
[4150]MYAPPNAME(138)/readconfig(2756): SSBLastRunVersion='2.4.2'
[4150]MYAPPNAME(138)/readconfig(2756): SSBLastRunEngineType='external|com.google.Chrome'
[4150]MYAPPNAME(138)/readconfig(2756): SSBLastRunEdited=''
[4150]MYAPPNAME(138)/readconfig(2750): SSBUpdateIgnoreVersions=( )
[4150]MYAPPNAME(138)/readconfig(2756): SSBPayloadPath='/Applications/Epichrome/Payload.noindex/ylluminate/MYAPPNAME'
[4150]MYAPPNAME(138)/readconfig(2756): SSBLastErrorGithubFatal=''
[4150]MYAPPNAME(138)/readconfig(2756): SSBLastErrorNMHInstall=''
[4150]MYAPPNAME(138)/readconfig(2756): SSBLastErrorFailsafe=''
[4150]MYAPPNAME(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 )
[4150]MYAPPNAME(226)/getepichromeinfo(261): Found Epichrome 2.4.2 at '/Applications/Epichrome/Epichrome.app'.
[4150]MYAPPNAME(226)/getepichromeinfo(340): Current version of Epichrome (2.4.2) found at '/Applications/Epichrome/Epichrome.app'
[4150]MYAPPNAME(237)/checkappupdate(377): No newer version found.
[4150]MYAPPNAME(256)/checkgithubupdate(680): Not yet due for GitHub update check.
[4150]MYAPPNAME(348)/getextenginesrcinfo(2126): Trying path '/Applications/Google Chrome.app'...
[4150]MYAPPNAME(348)/getextenginesrcinfo(2187): External engine Google Chrome 87.0.4280.141 found at '/Applications/Google Chrome.app'.
[4150]MYAPPNAME(477)/checkenginepayload(2404): Engine payload appears valid.
[4150]MYAPPNAME(534)/setenginestate(2487): Engine activated.
[4150]MYAPPNAME(545)/launchapp(2909): Launched engine with PID 4329.
[4150]MYAPPNAME(585)/writeconfig(2835): Configuration variables have not changed. No need to update.
[4150]MYAPPNAME(674): Waiting for engine to quit...
/users/ylluminate/Library/Application\ Support/Epichrome/Apps/MYAPPNAME/Logs/epichrome_app_log_20210408_143330.txt (END)
Yeah, this log looks like everything ran fine from Epichrome's perspective. Once the engine is running, it really is just Chrome (as you know) so there's very little I can do to diagnose problems after that point. Having not ever experienced this myself, I'm not sure what else I can do to diagnose it at this point. The main thing is to make sure that the engine was actually invoked with --user-data-dir (which you can see in ps as the engine is running). If that's the case, then the engine was launched properly, and if there's a problem with session retention, it's going on in Chrome somewhere. Beyond that, I'm a bit stumped what else to try right now...