TLDR: The gnome keyring daemon is causing authenticated web pages to not load. Kill the gnome-keyring-daemon process for a fast fix (sudo killall gnome-keyring-daemon). See below about how to keep this from happening.
If you are trying to login to websites on Chrome on a Linux desktop, and your browser freezes after clicking the login button, the Gnome keyring might be the cause of your agony.
On Linux, when Chrome loads a web page where credentials are involved, it seems there is a hook in the Gnome desktop software, where if Gnome keyring is turned on, it will try to save your credentials before allowing the web page to load in Chrome. Unfortunately, if the box for this does not pop up, or the pop up window is buried behind other windows, it looks like your Chrome web page (likely Firefox as well, but I have not checked) just freezes and it will not respond to any input at all.
For a fast fix you have to kill the gnome-keyring-daemon process. Usually it's just "sudo killall gnome-keyring-daemon". It might be called something else on your machine. I suggest looking for something with "keyring" in then name. After killing it your pages should load as expected. But your wondering how do you keep this from happening again?
To keep Gnome keyring from doing this to you again you can try a few things.
First thing to try is turning off the Gnome keyring daemon, if you are not going to use it. The daemon is used to store credentials like ssh keys or passwords for you. If you know your not going to use it just turn it off. Usually on different desktops there is a area in the settings that will show you what things run on desktop startup. You will have to find that for your Linux desktop distro (there are to many ways for to many desktops to list here), and see if Gnome keyring daemon is there. Then uncheck a box to turn it off. The logout and log back in.
The second way to handle this is to leave the keyring daemon on, and just set a blank password (insecure yes, but if you are not going to use it then who cares). For an example on how to do this in the MATE desktop you go to Applications -> accessories -> passwords and keys. Delete the "Default" Keyring that has the lock symbol. Close your browser and open it back up. Go to a web page that requires a login, and try to login. Gnome keyring should now ask you to choose a new password. Don't enter a password, and click the ok button. It will warn about credentials being unencrypted, but that is ok if your not going to put things in it. This will now keep it from opening again in the future.
TLDR: "rm -rf ~/.var/app/com.spotify.Client/" your Spotify home dir and start over.
I just installed the latest Flatpak (from flathub) of the Spotify client (22.214.171.1246.g416cacf1) on CentOS 7. After doing this and trying to start Spotify back up, it proceeded to just open the Spotify window very quickly, and then close itself. Trying to start it up from the command line gave some more output to try to diagnose this issue.
# start the spotify client from the command line flatpak run com.spotify.Client /app/extra/bin/spotify: /app/lib/libcurl-gnutls.so.4: no version information available (required by /app/extra/bin/spotify) [spotifywm] attached to spotify [spotifywm] spotify window found
After doing this, the window was nowhere to be found. I thought it might be and issue with the file it could not find which was the "libcurl-gnutls" error above. I eventually found out this had nothing to do with the issue and it could be ignored. Eventually the only thing that fixed this issue was removing my whole Spotify home dir (which wipes out any downloaded files, settings, and your login info). Removing the dir is easy as just deleting directory "rm -rf ~/.var/app/com.spotify.Client/". Then run the command to start up the Flatpak again "flatpak run com.spotify.Client". It should start right up and you will have to login again.
When trying to add a new partition to a hard drive, you used to be able to just unmount the drive and perform your work. In SystemV init style systems, the drive would never just mount itself back up without any type of action being taken like the mount command being run. Contrast this to systemd, where if you just unmount a drive to perform a task like a fsck or a re-partition, when you try to access the device the drive is attached to for example, with a partitioning software like parted, systemd will mount the drive back up. This makes it very difficult to do something that used to be very simple. I seem to say that a lot with systemd.
To actually keep the drive unmounted the whole time you do your work, you have to perform the following steps.
During system boot systemd takes all of the fstab entries and generates native mount units for them. If you edit something in fstab you have to tell systemd so it can re-generage new updated units for the fstab entries. This is what the "systemctl daemon-reload" does. This will re-run all generators, and cause systemd to reload units from disk. Read more about it here.