Why the web client sometimes struggles when more than a few tabs are open

Every tab open in the web client independently loads the entire contents of the notifications pane every 30 seconds in the background. This may not be a small payload (I may be an outlier?).

Each web client tab I have open continuously burns about 0.5 Mb per second of available download volume.

image

5 Likes

I’m trying something out. I sometimes work behind a connection that often hovers around 10 Mb download. If I’m navigating a task that jumps between 10 different tabs, then those tabs are bogarting half of my entire download capacity with this one background process. That’s not something I can live with.

On digging into the response value, what this is downloading is the entire contents of the system monitor. That doesn’t seem entirely necessary for general functionality, so I blocked it by adding (roughly) this line to ublock origin filters to see what would happen:

[redacted]/[redacted]/api/v2/odata/[redacted]/Ice.BO.SysMonitorSvc/GetMonitorDataKeepIdleTime

The initial result is an error message: “Cannot connect - Server not available” which pops out on every new tab. Once that message is dismissed, the 30 second cycle is broken and this particular HTTP method never runs again on that tab unless specifically requested.

Caveat, though. “Bell” notifications, downloads, exports, and print previews depend on system monitor results, because they depend on a notification to inform the client tabs that something exists. I can live without bell notifications. If I need to download, export, or print preview anything, disabling ublock origin for any tab is all that’s required. Adding a hard reload loads system monitor contents, if I should need them.

I’m wondering if a web worker might solve this by having only one thread checking for notifications and downloads regardless of the number of tabs. It could even work if the user has zero Kinetic tabs open. :thinking: