Chromium auto-restart feature breaks many features

Bug #1855489 reported by Alexis Wilke
This bug affects 1 person
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)

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.

Tags: auto-restart
Revision history for this message
Olivier Tilloy (osomon) wrote :

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

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.

Changed in chromium-browser (Ubuntu):
status: New → Incomplete
Revision history for this message
Alexis Wilke (alexis-m2osw) wrote :

Well, I can't really confirm whether it is a refresh (which I called auto-restart) after an auto-update or a an actual crash... but for sure the window does not change yet it gets disconnected from the Gnome Desktop (and that has happened many times now). At least I'll post to confirm that the history fails next time that happens and I'll check the versions to see whether it happens when an upgrade happens.

However, the problem doesn't look like bug #1616650 in terms of functionality, the tabs all remain in place and work just fine without having to restart for many days after it gets disconnected from Gnome. That being said, the read-only folder (point 2) sounds like that could be part of the issue. I'm also not so sure that there was an update. I'll now pay attention to the exact version and see whether it changes next time the dot under the icon disappear.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Alexis, the problem you're describing is definitely the automatic update mechanism that results in gnome-shell loosing track of the running instance of chromium.

I strongly suggest you run:

    snap set core experimental.refresh-app-awareness=true

and restart chromium. This should fix the problem.

Revision history for this message
Alexis Wilke (alexis-m2osw) wrote :

Okay, another updated happened today (version 79.0.3945.79) and I can confirm that it creates the issue where I lose the dot under the Gnome icon. So bug $1616650 definitely looks like the solution to this problem. Thank you.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.