Favicon notification breakdown: sticky black exclamation mark across browsers

The Syncthing favicon shown in my browser tab (across Firefox, Edge or Brave web browsers) is currently stuck in the notification state of ‘Notify’ (a white exclamation mark concentrically circumscribed in a filled black disk). Furthermore, no other state icons are shown regardless of whether the client is paused/resumed/syncing.

Heeding this question (though not strictly applicable as I am neither bookmarked nor restricted to Firefox), I deleted the browsers’ cache, restarted Syncthing and restarted the computer. None of these have solved the issue.

What is the cause and how to resolve it?

Syncthing v1.25.0
Pop!_OS 22.04 LTS
Firefox 116.0
Brave 1.58.135
Edge Version 119.0.2116.0

The main culprit is probably browser-side caching, rendering this status-icon rather useless. Here, it only seems to work somewhat well in Chrome…

But there’s also some weirdness under the hood, as here it gets triggered by the Syncthing-instance which serves the GUI having an ‘undefined’ connection state no matter what is actually happening. Sounds a bit weird to me, but alright.

I honestly think it’s probably best to move away from having an adaptable fav-icon and move it to somewhere inside the actual GUI.

I think it can’t be browser-side caching - since I barely use Edge, this was the first time the URL was ever entered into it, yet the bug sprung straight away. Also, clearing the cache made no difference.

The stuck warning-favicon has become a great source of anxiety for me - every now and then my eyes would wander to the tab making me fear if the sync has actually stopped (connection loss, drive full etc), then I would go and look at the page, find it was crying wolf, yet come away feeling uneasy that something, somewhere, deep down, must be broken and I will discover years later that sync hadn’t really been working at the time …

As to moving the badge inside the GUI, ironically, I disagree. Having a tiny notification badge right on the tab is pretty convenient (when it works properly)- at a glance the user can tell if Syncthing needs attention, or not, without having to open the page/tab.

Probably because it’s a double-folded issue; some oddness in deciding which icon to show combined with browser-side favicon caching (which I think is mostly a separate system/mechanism).

When the condition within the brackets is met, sure. But I personally doubt whether that’s possible as it’s usually not expected that the favicon changes on the fly and the results vary quite a bit depending on the used browser (when testing locally).

But I’m no front-end expert so perhaps there are possibilities. But otherwise no icon beats a faulty one any day.

I wonder why we load all js code at the end of the body instead of the head section?

Currently the UI falls over its own feet because the favicon is loaded without interpolation, causing an 404 HTTP error.

Somehow deviceStatus returns unknown for the device itself. This line is the culprit:

Apparently /rest/stats/device includes the device itself. As the device doesn’t have a connection to itself, the status switches to unknown.

1 Like

v1.24.0 used to provide a fake connection for the device itself via /rest/stats/connections. This seems to be the cause of the regression.

Looks like it was introduced by all: Support multiple device connections (fixes #141) by calmh · Pull Request #8918 · syncthing/syncthing · GitHub

Edit: Favicon is stuck in notify state · Issue #9149 · syncthing/syncthing · GitHub


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.