Bitwarden extension displays no entries when there is no internet connection (but an IP is assigned)

[oddlama]

Steps To Reproduce

1. Start Firefox while it has internet
2. Cut the internet connection (not the LAN connection)
3. Open extension and log in
4. Observe that the login itself is successful, but the window is not operational

Expected Result

Bitwarden should be usable even if some network requests are stalling indefinitely due to connectivity issues

Actual Result

The login itself is successful, and the extension shows the correct amount of matches in the little number besides the icon. But when clicking on it, it will open an empty window without any buttons or list entries instead of the usual extension window. (It just shows the background color, nothing else)

Screenshots or Videos

Additional Context

No response

Operating System

Linux

Operating System Version

NixOS unstable (24.11)

Web Browser

Firefox

Browser Version

127.0.1

Build Version

2024.6.3

Issue Tracking Info

• [X] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[leprechaun]

This sounds extremely similar to this forum thread.

[SergeantConfused]

Hi @oddlama,

Thank you for this report. Are you using the Bitwarden cloud (https://vault.bitwarden.com/#/), or are you self-hosting your own Bitwarden server locally?

Thank you in advance,

[oddlama]

I'm self-hosting. Correct me if I'm wrong but I don't think this is relevant in this particular case, since the issue occurs specifically when there is not internet 😅 So I would presume there's no difference in not reaching a self hosted instance and not reaching an official instance, or is there?

[SergeantConfused]

Hi @oddlama,

Thank you.

1. This sounds quite similar to this GitHub report; Could you please review it and let me know if that's the behaviour you're encountering?
2. I'm unable to reproduce this whilst unlocking a browser extension that's logged into a cloud Bitwarden account, within Chrome or Firefox; Are you able to? Knowing if this is isolated to self-hosted environments may be helpful.

Thank you in advance,

[oddlama]

The behaviour is similar but not exactly the same. If I cut the whole internet at my router, I get a background-colored screen all the time, and no amount of waiting will let me into my vault. This is what I reported here. A random guess is that this could happen because now all network requests will get no response and maybe there is a network request somewhere in the extension that has no timeout set and blocks the UI?

By cutting access only to the bitwarden specific endpoints I get the behaviour from the issue you linked. Although for me it just takes 10 seconds until it lets me into my vault and then another 5 seconds until all items are displayed, but overall it is usable. You can reproduce on a self hosted instance by just disabling the server, and also on bitwarden.com by rewriting identity.bitwarden.com and api.bitwarden.com in the hosts file to an IP address that doesn't respond at all (I used 123.13.13.13 arbitrarily):

# /etc/hosts
123.13.13.13 identity.bitwarden.com
123.13.13.13 api.bitwarden.com

I noticed that the vault loads instantly both on self-hosted and bitwarden.com if the remote connection responds by closing the socket. It is important that the connection times out to reproduce the bug. I can also reproduce the background-screen bug on bitwarden.com by cutting internet at the router level. Again it is important that the machine itself thinks it has a route and tries to route packets that just never get any response.

[khernyo]

I have the same experience as @oddlama described, although I have a workaround: delete a network interface.

I'm on Debian, and neither bitwarden desktop (version 2024.6.4), nor the firefox extension (version 2024.6.3) work as expected.

Output of ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet ***.***.***.***/** brd ***.***.***.*** scope global dynamic noprefixroute wlp0s20f3
       valid_lft 76796sec preferred_lft 76796sec
    inet6 ****::****:****:****:****/** scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: br-2559ee6d33b7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet ***.***.***.***/** brd ***.***.***.*** scope global br-2559ee6d33b7
       valid_lft forever preferred_lft forever
    inet6 ****::****:****:****:****/** scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
1071: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet ***.***.***.***/** brd ***.***.***.*** scope global docker0
       valid_lft forever preferred_lft forever
1072: zt******: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet ***.***.***.***/** brd ***.***.***.*** scope global zt******
       valid_lft forever preferred_lft forever
    inet6 ****::****:****:****:****/** scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

br-2559ee6d33b7 and docker0 are docker related, and zt****** is a zerotier interface.

When I start bitwarden desktop, and enter the password, it blocks indefinitely while showing the unlock screen. Now, when I delete any of the above three interfaces (e.g. ip link delete docker0), bitwarden proceeds with the unlocking and becomes usable. Closing and reopening bitwarden gets us back to the blocked unlock screen: I have to delete another network interface.

When I've delete all three interfaces, the behavior remains the same. At this point, I have three remaining network interfaces: lo, en, wl. Two of these have IPs assigned (lo, and wl*). This looks like a pretty regular setup to me, but the bitwarden desktop still doesn't work. Now I can proceed to restore the interfaces (by restarting the related services), and start deleting them again when I need to use bitwarden.

[oddlama]

When I've delete all three interfaces, the behavior remains the same. At this point, I have three remaining network interfaces: lo, en, wl. Two of these have IPs assigned (lo, and wl*). This looks like a pretty regular setup to me, but the bitwarden desktop still doesn't work. Now I can proceed to restore the interfaces (by restarting the related services), and start deleting them again when I need to use bitwarden.

To me this sounds like the process is blocking on a read or poll which is interrupted by the kernel because you changed your interface configuration. So there might be something in bitwarden that is missing a timeout, but I have not validated this.

[khernyo]

Bitwarden Desktop version 2024.4.3 works for me. The following versions don't: 2024.5.0, 2024.6.0, 2024.6.1, 2024.6.2, 2024.6.4. Didn't check 2024.6.3

[bendem]

Same here, the vault unlocks correctly because the badge shows some passwords have been found, but the display of the UI seems to be stuck waiting for a request that cannot happen since internet is down.

[SergeantConfused]

Hello everyone,

Thank you all for your input. Followed "I can also reproduce the background-screen bug on bitwarden.com by cutting internet at the router level." and was still unable to reproduce this with Bitwarden Add-on 2024.6.3 inside Firefox 128.0 on Windows 11 Pro 23H2.

1. For anyone that still is able to reproduce this, could you please uninstall the Firefox extension, remove any leftover data from the location outlined here for the browser extension, reboot the machine, install the Bitwarden browser extension anew inside Firefox, and let me know if that assists?
2. Is anyone encountering this behaviour on Windows?

Thank you again,

[khernyo]

I have not experienced the issue on Windows.

On Linux, Bitwarden Desktop still doesn't work after deleting the data.

The Firefox extension improves after reinstalling it: unlocking doesn't seem to work, it's still stuck waiting for something after entering the password. Closing and reopening the pop-up fixes it, though. So it's broken, but usable.

Just to be clear, both Bitwarden Desktop and the Firefox extension seem to be affected by the same issue, but it can be worked around in the extension by closing and reopening it, but not the Desktop. And it looks like the issue is only reproducible on Linux.

[khernyo]

Nope, sorry, the Firefox extension only works until the first vault lock. After that, it's back to the same behaviour: I need to disconnect the network for it to work.

[khernyo]

This is definitely not fixed in the latest released version: 2024.8.1. Is it supposed to be fixed in that version, or is it planned for a later release?

I get the same behavior with the new firefox extension version.

There is one improvement with the desktop app: the login screen freezes for about 30s, but after that I get to browse my passwords, but it's probably stale data:

• sync doesn't work
• save doesn't work

This is the output to the terminal during login:

14:10:57.026 › Error refreshing access token:  Error: Failed to fetch
14:11:04.492 › Error: Failed to fetch
14:11:27.166 › Unhandled error in angular Error: Uncaught (in promise): TypeError: Failed to fetch
TypeError: Failed to fetch
    at file:///opt/Bitwarden/resources/app.asar/app/vendor.js:2:825382
    at r.<computed> (file:///opt/Bitwarden/resources/app.asar/app/vendor.js:2:819378)
    at useClass.nativeFetch (file:///opt/Bitwarden/resources/app.asar/app/main.js:149:80400)
    at useClass.<anonymous> (file:///opt/Bitwarden/resources/app.asar/app/main.js:149:80360)
    at Generator.next (<anonymous>)
    at o (file:///opt/Bitwarden/resources/app.asar/app/main.js:90:382923)
    at c.invoke (file:///opt/Bitwarden/resources/app.asar/app/vendor.js:2:812487)
    at Object.onInvoke (file:///opt/Bitwarden/resources/app.asar/app/vendor.js:2:2122960)
    at c.invoke (file:///opt/Bitwarden/resources/app.asar/app/vendor.js:2:812427)
    at o.run (file:///opt/Bitwarden/resources/app.asar/app/vendor.js:2:807880)
14:11:27.462 › Unable to fetch ServerConfig from https://api.bitwarden.com: Failed to fetch
14:11:27.463 › Starting decryption using multithreading
14:11:27.464 › Starting decryption using multithreading
14:11:27.826 › Finished search indexing

This is what I get when clicking File > Sync vault:

14:12:18.452 › Error refreshing access token:  Error: Failed to fetch

Trying to save a new passoword:

14:13:03.353 › Unable to fetch ServerConfig from https://api.bitwarden.com: Failed to fetch
14:13:03.653 › Error: Failed to fetch
14:13:03.653 › Received API exception: Error: Failed to fetch
14:13:33.473 › Error: Failed to fetch
14:13:33.492 › Received API exception: Error: Failed to fetch

[djsmith85]

@khernyo As previously stated here. The changes made with #10452 were not included in 2024.8.1, but will be included in the next major browser release.

[rchomat]

@djsmith85 this should be released as a hotfix as it's completely breaking the app since several month now ! That's unusable unless you wait several minutes to get access to your vault !

[prigal]

Running 2024.9.0 on firefox, problem is still there :

[rchomat]

@prigal the fix is not in the 2024.9.0 and should be in a next release (don't know which one nor when) More info (if I can say so..) in the issue #9561