Browser disconnection redirects the browser to /ajax/stats.php

[andrey-utkin]

A browser tab with Bluecherry web UI would by itself jump to ...:7001/ajax/stats.php and present an odd "XML error" screen.

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<stats>
<cpu-usage>0.3</cpu-usage>
<memory-total>8026680</memory-total>
<memory-inuse>525776</memory-inuse>
<memory-used-percentage>6.55</memory-used-percentage>
<bc-server-running>up</bc-server-running>
<server-uptime>0 day(s), 08:53:52</server-uptime>
<server-status>
<pid>267</pid>
<timestamp>1705108847</timestamp>
<message/>
</server-status>
</stats>

So this XML thing happens after the browser is disconnected from the internet (so that background webpage update request fails) and then is connected again:

Request failed redirecting to /ajax/stats.php main.js:245:25
    hz https://bc-d:7001/template/dist/js/main.js?v=1705359856:245
    jQuery 6
    send https://bc-d:7001/template/dist/js/main.js?v=1705359856:219
    manReq https://bc-d:7001/template/dist/js/main.js?v=1705359856:512
    updateStatData https://bc-d:7001/template/dist/js/main.js?v=1705359856:81
    <anonymous> https://bc-d:7001/template/dist/js/main.js?v=1705359856:123
XML Parsing Error: not well-formed
Location: 
Line Number 1, Column 103:
InstallTrigger is deprecated and will be removed in the future. constants.js:50:14
XML Parsing Error: not well-formed
Location: 
Line Number 17, Column 51:
SyntaxError: An invalid or illegal string was specified  content-script.js:39

The JS code backtrace begins at the line added here:
3c510b2
#474

[JahleelAbraham]

I have managed to recreate this bug, looking into it now

[andrey-utkin]

The commit which causes the troublesome redirect is 3c510b2 . Let's refer to it as "historical commit".

The historical bugreport and the discussion which led to that patch is #474

Jahleel's work in progress is on a branch https://github.com/bluecherrydvr/bluecherry-apps/tree/bug/654-redirect-to-stats.php-on-disconnect

Jahleel's solution takes defensive approach which is appropriate if we are concerned about the reappearance of the historical issue.

My personal opinion is that the historical commit is just bad and should be reverted as the first step. Let's see if the original issue reoccurs - uBlockOrigin is a moving target and it might have changed its behaviour. The very idea of redirect if a request failed strikes me as odd, so if we need to fix the historical issue somehow, I'd rather we solve it differently. But I doubt the old issue would even be observed.