Chromium auto-restart feature breaks many features
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
chromium-browser (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
Once in a while, Chromium "auto-restarts" to take advantage of new features and especially apply security patches. This sounds like a great feature only it currently has very bad repercussions (as in, it's terribly bogus).
Steps to reproduce:
1. start Chromium
2. browse to various pages
3. let the app. sit there until it auto-restarts
4. from this point on, the app. is bogus, it's not able to save many different things
5. restarting the app. will not see all changes you make between step 3 and 5 (see below)
Note that the duration of the session is probably not an issue in itself. I think only the auto-restart feature is what causes all the other issues.
The features I've noticed that broke completely after such a restart:
(1) Gnome Icon
The small arrow in the Chromium Icon from my Gnome toolbar (the bar which by default is on the left side of the screen) disappears. That in itself is not the end of the world except that this means I can't click the icon to go back to my window. Clicking the icon opens a new instance.
To fix this problem, you would have to run an additional binary. The first binary has to remain in place to hold the icon as expected. Without doing that, you lose the connection to Gnome. There may be other methods to do that. It may also be because you close the old connection to X-Windows and Gnome views that as "now you're gone". Either way, this is not too important to me and it's not a big bad bug in itself.
(2) Trying to Install Extensions generates: "Could not create download directory"
As such, this error doesn't sound too bad. You should be able to tweak your directory and make sure that it's writable. The fact is that my download directory was just fine. However, it looks like Chrome doesn't think it is.
My take is that Chrome has a form of lock and the old lock is still in place making it impossible for new version to access the folders that are locked.
This is rather bad since many functionalities may be affected by this. I've only noticed the problem with downloading extensions, but it is not unlikely that other features are also affected in a similar manner.
(3) Changing Settings
As I was in that situation, I thought I would change my "On Startup" settings so that I could get my windows back on a restart. That way the restart is mostly transparent. Oh but...
The changes to the settings did not take; while still using Chromium it looked like it was properly changed, but it was not auto-saved as it ought to be. I am thinking that a similar lock (as mentioned in the previous section) is still in place and it prevents the settings from being saved.
(4) Non-Existent History
After my restart, the windows did not come back. That is, I only got two windows from a while back... Not the newest windows as I would expect. (i.e. all the windows at the time I last closed the browser).
So I decided to check out the history. Nothing. I could only see history from many days ago. Again, my take is that when we had that background auto-restart of Chromium, it was not able to access the history file. It kept the history in memory and never told anyone it couldn't save it anywhere. (Maybe the logs are also affected... I've not checked. But that could explain why developers did not notice and I would imagine that developers open/close the app. all the time).
I think this is the worst one. I like to have my history so I can go back to pages where I have been in the past. I don't always use it, but in this very situation I was interested by one specific page and the link is gone.
-----
Note 1: I'm on Ubuntu 18.04 using the Chromium snap version 78.0.3904.108 (64 bit).
Note 2: I insist that changing the Download folder had no effects. That's not the issue in this case. Also, I could download files and they would go in my ~/Downloads folder as expected. No problem on that one.
I'm not aware of such a feature (auto-restart).
Did you mean auto-update? The snap will indeed automatically update in the background, which may cause some issues if the app is already running. This is being tracked by bug #1616650, and I suggest you try setting the experimental. refresh- app-awareness flag to true (see https:/ /forum. snapcraft. io/t/wip- refresh- app-awareness/ 10736).
If chromium restarts under your feet while you're using it, that's probably a crash, and I'd be interested in steps you take to reproduce it.