App created with 2.3.0 & Brave losing state (login & corrent page)

[kdambekalns]

I created two apps using 2.3.0 from scratch, using Brave as engine. The apps work fine, but after quitting and reopening, I need to log in again (it keeps the login on a third app, though…). And I always start up at the "default" page, i.e. the URL entered when creating the app. Even when setting Brave to "start were I left off" in the settings.

Is that expected behavior? It used to be different…

[kdambekalns]

Oh, and it asks for saving the password every time, even if I click save.

[gregschroeder]

+1

I've tried this with fresh Brave Epichrome SSBs and with ones I've upgraded to Brave from 2.2.x, and it is as if cookies are not saving (need to login each time, remember me is a no-op, etc), and passwords are not saving in the browser (brave://settings/passwords says "Saved passwords will appear here" after I've saved it, repeatedly - and even after an import). I made no changes whatsoever to the settings after letting Epichrome create the apps.

Combined with the non-support for 1Password6, this means a rather laborious login each time I open any Epichrome SSB. I thought I could live without 1P and just use the built in browser password management, especially since most of my SSBs would only need one account credential set. Frustrating..

This seems to be a problem with Brave - see https://github.com/brave/brave-browser/issues/4061 and its many related tickets.

Related to a suggested workaround in that ticket, I tried deleting ~/Library/Application Support/Epichrome/Apps/MYAPP/UserData/Default/Login Data*, but that didn't seem to make any difference.

If this does require a new version of Brave (assuming a fix there), and we're only using Brave by way of Epichrome apps, how will the apps get updated? Since you tell us not to use the auto-update from within each app, will you release a new Epichrome version every time there is a Brave release?

Thanks!

[gregschroeder]

fyi, I created two test SSBs, 'testing1' (Brave) and 'testing2' (Chrome). The Brave one had the problems above - required login, no passwords saved in settings. The Chrome one worked fine and as expected.

I installed the Edit This Cookie extension, and sure enough, in the Brave version, cookies were not saved across a restart of the app.

[dmarmor]

This is a problem I saw with a few users during early betas, but seemed to have cleared itself up. I never exactly figured out what combination of events caused it, but it's something to do with corrupted settings or session data causing Brave to not request access to Brave Safe Storage in your user keychain. The most reliable solution I've found is to delete all of the problem apps' browser data and delete Brave Safe Storage from your keychain. Here's how to try this with one of your misbehaving apps:

1. Delete the UserData directory in your app's data directory (~/Library/Application Support/Epichrome/Apps/<AppID>/UserData).

2. Run Keychain Access and search for "Brave". You should see a window like this:

   

3. Delete the Brave Safe Storage item.

The first time you run the app, you should most likely see a dialog like this:

If so, you should enter your login password and click Always Allow. I've found, though, that sometimes this dialog doesn't appear and yet things still work. There are two ways to check.

1. Once the app is running, open Keychain Access again and search for "Brave". Double-click Brave Safe Storage and click the Access Control button at the top. You should see something like this:

   

2. The definitive test then is to enter a login/password to a site that you know will keep you logged in (I actually use GitHub to test this) and save the password in Brave. Then quit the app and run it again. You should still be logged in, and if you go to Settings, you should see the password in your saved passwords.

If this works with the test app, then I'd recommend you do just the first step of deleting the UserData directory for all your other misbehaving apps (you shouldn't need to re-delete Brave Safe Storage), then run each one again, and they should add themselves to that key.

Please let me know how this goes and if it fixes those apps for you!

[gregschroeder]

Nope :(

I deleted the UserData folder of the existing app as directed, and deleted 'Brave' from the Keychain, and retried. Same.

Note that it does not show me that Allow dialog - ever. I have tried a full sequence of quit app, delete dir, delete Keychain (although it was only ever there the first time), restart Mac, reopen app, put in credentials. I am prompted by the browser to save the credentials (each time), but never by Keychain.

When I restart the app after a purge, the Epichrome start page tells me that the app has been reset. And, as implied by never being prompted by Keychain, nothing ever gets stored there, and the login info is not retained across app instances.

I also just tried this again creating a brand new app via Epichrome (after a fresh reboot, in case there are odd cache issues), and the same exact thing happens on the new one - never get the Keychain prompt, Keychain search for 'brave' returns nothing, and the SSB credentials do not persist.

BTW, when I create these disposable test SSBs, I've discovered that I now have to remove them from /Applications/Epichrome/EpichromeEngines.noindex/, or they remain registered after they're deleted and then I would get launch fail dialogs trying to open URLs. Took me forever to find those (lsregister was the answer.)

[gregschroeder]

FYI, just tried again with 2.3.1 - no change. I created a brand new test SSB, doesn't cause a Keychain prompt for access (and it remains empty of 'brave' entries), and the browser doesn't keep the credentials.

[kdambekalns]

Tried removing UserData and the keychain entry. No prompt, no change in behaviour. Still, one app works, the others don't.

[gregschroeder]

does this have something to do with Brave being installed, or not being installed, as a standalone browser? it occurred to me above in the Keychain discussion that it was simply one global 'Brave'.

I do not currently have Brave installed as a standalone browser, but I did, and had uninstalled it. It has been uninstalled during these recent experiments, but I can't be certain that there isn't a relic remaining from when it was. (I used TrashMe which is pretty good about finding the app-support bits et al). Because of the 1Password6 extension issue, it is unfortunately of no use to me as a general browser, so I removed it, but could put it back if that's a requirement.

[dmarmor]

You know, I had had the same exact thought when I read your first reply this morning. If not too much trouble, I'd be interested to know if deleting Brave Safe Storage, then installing Brave and running it might make any difference. First thing would be to make sure that Brave itself creates that item. Assuming it does, then try deleting the UserData of one of the problem apps and run it and see if your luck changes. I'll be very interested to know if it does! If that's the case I'll probably need to require that people using the built-in engine still have Brave installed on their systems...

[gregschroeder]

I reinstalled Brave. It prompted for Keychain Access, I said Always Allow. It didn't make any entries until I had it save some credentials for a site.

I then deleted User Data for an existing problematic SSB. The Epichrome page noted that the app had been reset, but it never prompted for any Keychain permissions, and still doesn't save state.

I then tried creating a new SSB from scratch; no change.

:(

[kdambekalns]

For me it seems to work now… all I did was… nothing. Well, not really. I rebooted my Mac today. When starting the app that has had working "remember login" behavior, I was asked to give keychain access. Doh! And when starting another (so far non-working app), I was asked to update to 2.3.1 (which I did), and entered my login (again). Now, when restarting that app, I am still logged in. 🥳

[dmarmor]

Thanks for the udpate, @kdambekalns and I'm glad at least it's working for you now, though it is mystifying as to why. Ive still never been able to replicate this reliably on my own system so it's been super frustrating to try to fix it. I just have to keep asking people to try random stuff on their systems.

To that end, @gregschroeder, would it be all right if I message you separately to try another experiment?

[purevertigo]

@dmarmor Is there a fix in the works for this? I am aware that this is the same issue I was having in the other post that has been closed because of duplicity.

[purevertigo]

This is a problem I saw with a few users during early betas, but seemed to have cleared itself up. I never exactly figured out what combination of events caused it, but it's something to do with corrupted settings or session data causing Brave to not request access to Brave Safe Storage in your user keychain. The most reliable solution I've found is to delete all of the problem apps' browser data and delete Brave Safe Storage from your keychain. Here's how to try this with one of your misbehaving apps:

1. Delete the UserData directory in your app's data directory (~/Library/Application Support/Epichrome/Apps/<AppID>/UserData).
2. Run Keychain Access and search for "Brave". You should see a window like this:

1. Delete the Brave Safe Storage item.

The first time you run the app, you should most likely see a dialog like this:

If so, you should enter your login password and click Always Allow. I've found, though, that sometimes this dialog doesn't appear and yet things still work. There are two ways to check.

1. Once the app is running, open Keychain Access again and search for "Brave". Double-click Brave Safe Storage and click the Access Control button at the top. You should see something like this:

1. The definitive test then is to enter a login/password to a site that you know will keep you logged in (I actually use GitHub to test this) and save the password in Brave. Then quit the app and run it again. You should still be logged in, and if you go to Settings, you should see the password in your saved passwords.

If this works with the test app, then I'd recommend you do just the first step of deleting the UserData directory for all your other misbehaving apps (you shouldn't need to re-delete Brave Safe Storage), then run each one again, and they should add themselves to that key.

Please let me know how this goes and if it fixes those apps for you!

Tried this. No difference.

[dmarmor]

Hi @purevertigo, as you can see from the thread above I'm still trying to diagnose it. I won't know how to fix it (or if I can) until I know what's causing it. Stay subscribed here and you'll see any updates.

[dmarmor]

So while I was working on a fix for a different issue I found a way to sort of codesign the Brave engine executable, which got me wondering if that might improve matters at all on this issue. Anybody experiencing this, would you mind trying this beta and see if it gets your app to properly save session data and passwords?

This is a beta and not fully tested, so please back up your app before trying the update so you can roll back if necessary. The easiest way to do this is to just compress it in the Finder.

[purevertigo]

@dmarmor confirmed as 100% fixed. Login state is kept after quitting and re-opening.

Well done!

[dmarmor]

That's great, @purevertigo ! Glad to hear it's fixed things for you. This change will be in 2.3.2 which I'm releasing very soon, so hopefully it will fix the problem for everyone. Thank you all for helping identify this problem!

[dmarmor]

I've just released 2.3.2 with the codesigning fix. @gregschroeder and @kdambekalns, if you still have any Brave apps you can test with this version, I'd love to know if this issue is fixed. Thanks!

[aagarw33]

Hey @dmarmor I tested this on the new version today. I have 3 Brave apps (gmail, github and Jira). I have not seen any problems with gmail and github on closing and reopening the app but in case of Jira I am getting the login page every time I re open. Jira website is behind SSO does it matter?

Thanks.

[dmarmor]

Hi @aagarw33, I wouldn't think SSO would cause problems. The first test I'd be interested in is if you open a new tab in your Jira app and go to Github (which you know is persistent in its own app). Log in there, then quit the app, and then re-run. When you open a new tab and go back to Github, are you still logged in there?

[aagarw33]

@dmarmor I am still logged in at Github but not on Jira.

[dmarmor]

That means that Brave is able to save session state, so the problem is likely either with Jira itself, or some combination of Jira and Brave. Are you able to stay logged in to Jira across quit/restart on regular Chrome? If so, and you don't mind installing the actual Brave Browser on your system, at least temporarily, I'd be very curious to know if you can stay logged in to Jira on that across quit/restart. Thanks!

[aagarw33]

I see the same behavior on Chrome probably something wrong with the SSO site. Sorry for the alarm.

[dmarmor]

No worries at all. I'm glad the app state is being properly saved!