dmarmor
Extension data lost after Chrome 83 upgrade
@dmarmor asked me to open this issue in #228:
Regarding your problem with losing extension data, can you open a separate issue with as much info as you can give me (did you switch engines on update, any logs generated, etc.). I'd like to keep this issue focused on the inability to update 2.2.4 apps at all. Thanks!
I'm using Mojave, and when Chrome self-upgraded to version 83, I lost the ability to run at least one of my Epichrome applications (haven't tried the others yet). I installed Epichrome 2.3.1 but couldn't upgrade for the reasons detailed in #228, but was finally able to use the bash -x Epichrome trick to upgrade. Now the application runs, but I lost all data associated with the extensions I had installed in that Epichrome application (the same extensions in regular Chrome kept their data).
I didn't switch engines (still using Chrome) and didn't get any logs other than the "couldn't filter Info.plist" message. I'm using Mojave.
Might the data files for these extensions be around somewhere still? If so, where?
There's a lot of code in 2.3.x dedicated to not losing extension state on update, but actually when the engine stays the same, there should be no danger of it. The extensions and their data should all be in the app's browser profile, which is in ~/Library/Application Support/Epichrome/Apps/<YourAppID>/UserData. Meantime, a couple questions:
-
When you completed the update, did the extensions themselves go away? Or are they still installed but just with all their settings lost?
-
What did the welcome page say about extensions on first run of the updated app? If extensions were deleted, it should have listed them for easier reinstallation. (You can find this page archived in your bookmarks in a folder on the bookmarks bar titled
<YourApp> App Info.)
Thanks!
The extensions and their data should all be in the app's browser profile, which is in
~/Library/Application Support/Epichrome/Apps/<YourAppID>/UserData
Well, my older copy of this app doesn't even have a UserData folder (what's the older directory layout like?), and the new one does, but even though I reinstalled the extension in question (Session Buddy, FWIW), I'm not seeing where in that folder it would be. Where does extension data live in there?
When you completed the update, did the extensions themselves go away? Or are they still installed but just with all their settings lost?
They went away. I was hoping that the settings files would still have been present so that I could have used them as before once I reinstalled them, but it was not to be.
What did the welcome page say about extensions on first run of the updated app? If extensions were deleted, it should have listed them for easier reinstallation.
It did! (Or, at least, it listed the ones that it found installed in my regular copy of Chrome.)
No, the 2.2.4 layout just has the browser data directly in the app's data directory--that's all that's in there. But if you've updated the app, the update process would've (or should've) automatically moved everything into the UserData directory. So if you don't see that subfolder, it seems like either the update didn't really happen or something went drastically wrong. If you see a big mess, like you still have all the browser data in the main data directory, but also a UserData subdirectory and a config.sh file and a Welcome folder and such, then somehow the update didn't move the browser data, and then when you ran the app, it created a brand new browser profile (which would explain why all your extensions are gone).
If that's the case, then the solution is to make sure the app is not running, then in the Finder delete everything from the UserData directory, and then move all the browser stuff into the UserData directory. Basically this would be all the stuff in the main data directory, except:
config.sh
Engine
lock
Logs
pause
stderr.txt
stdout.txt
UserData
Welcome
Note that some of these may not be there (particularly lock and pause probably should not be there if the app isn't running).
Please let me know if this is the situation you see, and if moving those files restores your extension state.
But if you've updated the app, the update process would've (or should've) automatically moved everything into the UserData directory. So if you don't see that subfolder, it seems like either the update didn't really happen or something went drastically wrong.
Oh, no, UserData is there. I just also have another Epichrome app with a similar name that seems to be an older version, so I was comparing the two directories and trying to see what I could figure out. Sorry for the confusion.
So again, given that I do have a UserData directory, where would I expect the extension data to live in there?
So extension data is stored in various places, and I don't actually know where all of them are, as Chromium doesn't document that well. Installed extensions themselves are found in:
UserData/Default/Extensions
I've found that most extensions store their data in:
UserData/Default/Local Extension Settings
So that has been the folder I've been careful to preserve when an engine change for instance is going to remove extension. But in your case that's clearly not what happened. For some reason it appears to me that when you did the update you lost the entire browser profile and the app just created a new one, so you lost all your extension and their settings. I don't know why, as this shouldn't be possible, but I suspect you will not find either of the directories I mentioned above. I hope I'm wrong.
Please do let me know what you find, and if you experience anything like this again, let me know right away so we can try some diagnostics to see what might be going on.
Thanks. The only folders in Local Extension Settings are ghbmnnjooekpmoecnnnilnnbdlolhkhi (which is the ID that corresponds to Google Docs) and ngbmbabjgimgbfobhfhjpfhpmpnhbeea (which appears to be Epichrome itself). There's nothing there called edacconmaakjimmfgnblocblbcdcpbko (Session Buddy's ID), although of course there is a folder by that name in Extensions, since I reinstalled it.
Let me see what I can find elsewhere by that name...
Hmm. There is UserData/Default/databases/chrome-extension_edacconmaakjimmfgnblocblbcdcpbko_0...
In fact, I wonder if this is the issue. Session Buddy stores most of its useful data in an SQLite DB. Does Epichrome consider these DBs when upgrading?
FYI: i hat the same lost of data of Session Buddy while updating. Had to restore it from a backup...
I've never used Session Buddy. I'll install it in one of my test apps and see if I can figure out what's going on.
@talleux, did you switch engines using SSBAllowEngineSwitch during your update? I'm trying to figure out how this database got lost, when in a normal update Epichrome shouldn't touch the UserData/Default directory at all...
@marnen, it appears that losing your Session Buddy data was related to losing all the extensions. I'm still not sure what went wrong with your update, but it appears to me your entire browser profile was somehow lost in the update. Without more info on what went wrong there, I'm not sure I can figure it out. If you have another problem with an update like that, please let me know right away so I can look at the logs and try to figure it out.
One small consolation with all this is that you've made me aware of extensions that store their info in the database directory, so I will experiment with whether that can be preserved across engine switches for the next version.
@dmarmor Good to know, and of course I'll give you more info if I find anything useful from future upgrades.
Do note, though, that I wasn't switching engines, unless you simply mean between different versions of Chrome.
Yes! That's why I'm still confused as to why you lost all your extensions and everything. It would make more sense if you were switching engines. I'm hoping it was just a fluke and won't happen again, but if it does I definitely want to track it down.
Just fyi the same issue happened to one of my Epichrome's profile as well. Everthing regarding that one profile 'disappeared'.
I'm not sure whether I can help with debugging since by now I've just recreated everything from scratch. There's a possibility that this particular browser instance was running during update (I can't be sure since I don't remember exactly).
I can't think why the app running during update would cause this particular problem, but I suppose it is possible. If you do still have the logs directory for the app (it would be in ~/Library/Application Support/Epichrome/Apps/<AppID>/Logs) it'd be very useful to me if you could send me a zip of it. If you don't want to post it here, reply to this message and we can work out a way for you to send it to me directly. Thanks!