side menu or log window closes after a few seconds

[SemvdH]

Describe the bug
When trying to view the side menu or the log window, after a few seconds the window closes and you go back to the buttons overview. This happens from about a second to a few seconds after opening the side menu. The hamburger goes back to the default state, but sometimes stays in the active state.

To Reproduce
Steps to reproduce the behavior:

1. Click on the side menu hamburger
2. wait a few seconds
3. See the side menu close
4. Click on the side menu hamburger again
5. Click on Logs
6. wait a few seconds
7. See the log window close

Expected behavior
I expect the side menu and the log window to stay open.

Screenshots
bug gif

Additional context
Version: 2024.04.28 | Server connection: REST, WebSocket
OliveTin running on Ubuntu 22.04, installed through amd64 deb package

[jamesread]

Hey @SemvdH ,

Thanks for taking the time to report this, I really appreciate it and well try to fix it for you if we can track down the bug together.

Has this just started happening with a new update OliveTin, or are you a new user of OliveTin / it's always happened?

Thanks for including the gif, but sadly it doesn't seem to load?

[jamesread]

@SemvdH , ah, I see the gif now, that is weirddd.

What browser are you using there?

I can see in the footer that the OliveTin websocket isn't connected - that could possibly be causing issues. Can you open your browser's web deveoper console and look for any errors?

[SemvdH]

hi @jamesread , Thanks for the reply!

I was using Chrome. I updated from an early 2023 version (I think march 2023) to the latest version. After updating I noticed the issue.

After checking the console, I do indeed see some errors. There is an error message displayed with Firefox cannot connect to the server at wss://<my hostname>/websocket.

error { target: WebSocket, isTrusted: true, srcElement: WebSocket, currentTarget: WebSocket, eventPhase: 2, bubbles: false, cancelable: false, returnValue: true, defaultPrevented: false, composed: false, … }
​
bubbles: false
​
cancelBubble: false
​
cancelable: false
​
composed: false
​
currentTarget: null
​
defaultPrevented: false
​
eventPhase: 0
​
explicitOriginalTarget: WebSocket { url: "wss://<my hostname>/websocket", readyState: 3, bufferedAmount: 0, … }
​
isTrusted: true
​
originalTarget: WebSocket { url: "wss://<my hostname>/websocket", readyState: 3, bufferedAmount: 0, … }
​
returnValue: true
​
srcElement: WebSocket { url: "wss://<my hostname>/websocket", readyState: 3, bufferedAmount: 0, … }
​
target: WebSocket { url: "wss://<my hostname>/websocket", readyState: 3, bufferedAmount: 0, … }
​
timeStamp: 18320
​
type: "error"
​
<get isTrusted()>: function isTrusted()
​
<prototype>: EventPrototype { composedPath: composedPath(), stopPropagation: stopPropagation(), stopImmediatePropagation: stopImmediatePropagation(), … }
[websocket.js:55:10](https://<my hostname>/js/websocket.js)
    c websocket.js:55
    (Async: EventListener.handleEvent)
    h websocket.js:23
    h websocket.js:25
    c websocket.js:54
    (Async: EventListener.handleEvent)
    h websocket.js:23
    h websocket.js:25
    c websocket.js:54
    (Async: EventListener.handleEvent)
    h websocket.js:23
    h websocket.js:25
    c websocket.js:54

There is also a 400 Bad Request error on a GET wss://<my hostname>/websocket request.

It's probably the WSS GET request, could there be something wrong with my installation? The difference between the version I updated from and the version I am running now is pretty big

[jamesread]

Yeah, there have been quite a few changes between those versions - including adding websocket support.

OliveTin is probably unable to connect back to itself on a websocket because of a reverse proxy configuration. Are you using a reverse proxy here? If so, could you dump your config?

Note that the logs you posted include the full public URL to your OliveTin instance, so you may want to hide that / put some security in front of it.

[jamesread]

Okay, I can now see what's happening.

1. OliveTin isn't connecting on the websocket.
2. Therefore, it's fallen back to try and poll the API every 3 seconds about button status
3. When it gets a reply from the API, it's "redrawing", and a fairly recent code change would force the sidebar closed when it redraws.

The fix plan is we should work out why your websocket isn't connecting (I bet that's a reverse proxy issue), but secondly, probably force-closing the sidebar is a bug if we fallback to this mode without websockets.

[SemvdH]

I indeed use nginx as a reverse proxy, here's my config:

server {
        server_name <my hostname> www.<my hostname>;
        location / {

                proxy_pass http://10.10.10.101:8004;
                proxy_http_version 1.1;
        }



    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/<my hostname>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<my hostname>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}
server {
    if ($host = www.<my hostname>) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = <my hostname>) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        server_name <my hostname> www.<my hostname>;
    listen 80;
    return 404; # managed by Certbot
}

[jamesread]

@SemvdH Yep, we need to add a couple of extra statements to that config now to handle websockets. It's documented here - https://docs.olivetin.app/nginx-dns.html - but this should be the only extra bit you need;

    location /websocket {
        proxy_set_header Upgrade "websocket";
        proxy_set_header Connection "upgrade";
        proxy_pass http://localhost:1337/websocket;
    }

[SemvdH]

@jamesread That seems to have solved the issue, thanks a lot! Guess I should've checked the documentation a bit more...

[jamesread]

@SemvdH No problem, it's not a problem with you checking the documentation, it's just that a major new communication setting was added (websocket) which needed updated reverse proxy configs - seems like a weird reason for the sidebar to flash in and out! (I assume that is now fixed?)

I'll keep this bug open, as I'll try to address the underlying cause of the sidebar flashing in and out.

[jamesread]

OliveTin now hard relies on websocket, and will display a big red error message if it isn't available. This means the the sidebar closing/opening is irrelevant, the websocket connection should be fixed.