Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Realtime updates stop after first load of Frontends #259

Open
justparking opened this issue Oct 14, 2022 · 9 comments
Open

Realtime updates stop after first load of Frontends #259

justparking opened this issue Oct 14, 2022 · 9 comments
Labels
cannot reproduce Not being able to reproduce makes it very difficult to solve problem.

Comments

@justparking
Copy link
Contributor

e.g. a Dashboard will load in Safari but then not necessarily update. This may happen in Chrome too.

@justparking justparking reopened this Nov 28, 2022
@justparking justparking added the cannot reproduce Not being able to reproduce makes it very difficult to solve problem. label Nov 28, 2022
@justparking
Copy link
Contributor Author

This has been discussed with a few people but we've been unable to reproduce it.

If anyone can reproduce it, there's a much better change of being able to fix it.

Closing for now.

@thefennecdeer
Copy link

thefennecdeer commented Aug 22, 2023

Sorry to necro this issue, but I've recently been able to pretty consistently recreate it on an iPad and Safari.

  1. Open and load Frontend
  2. Go to homescreen and lock / Switch to another app for around 20~ seconds
  3. Switching back to Safari no longer shows the "Offline - Please Wait" message, and will stop updating the UI based on events.

I've been able to get it to desync within one or two tries - there seems to be an un-sweet spot where if you open it again too quickly, it's still connected, and if you wait too long, the tab refreshes.
Once it is in this state, it doesn't come update until quitting and re-opening.

For some context on our use case:

  1. Learning Facilitators enter the room, grab an iPad, use the frontend to set the room mode, then switch to a Room Login webpage for teachers.
  2. Teachers log in to a session, and set down the iPad
  3. Learning Facilitators later go to troubleshoot a device through the frontend / change room mode, and no longer get feedback through the UI.

Actions (e.g through buttons) still send, just kind of running blind though.

@mcartmel
Copy link
Contributor

I also can't reproduce the behaviour, but I have a possible fix if you would like to give it a try. This needs to be added just below the socket.onclose event handler within the updateLogs function in nodel.js.

        socket.onclose = function(){
          console.log('Socket Status: '+socket.readyState+' (Closed)');
          offline();
          $('body').data('update', setTimeout(function() { updateLogs(); }, 1000));
        } 
        // insert the following
        $(window).on("focus.socket", function() {
          if(socket.readyState==3){
            console.log('Socket Status: '+socket.readyState+' (Closed)');
            offline();
            $('body').data('update', setTimeout(function() { updateLogs(); }, 1000)); 
          }
        }); // end 

@dargs
Copy link

dargs commented Aug 23, 2023

Sorry to necro this issue, but I've recently been able to pretty consistently recreate it on an iPad and Safari.

We notice the same behaviour, if an iPad is left showing just a dashboard via safari, it'll be ok for months, but the iPads that we open/close browsers to open other dashboards, will suffer this glitch of not updating status/events.

Will try to try your solution @mcartmel .

@thefennecdeer
Copy link

Unfortunately @mcartmel's solution didn't work for me, but I found an easier way to reproduce the issue:
While on the page, turning off wi-fi with control centre and then turning back on results in the same behaviour.

Looking at the console through safari on mac, I can see that the iPad is still successfully making requests to hasRestarted, but still isn't updating the frontend.

@mcartmel
Copy link
Contributor

mcartmel commented Sep 6, 2023

Can you please test again with this code? I added a line to output the socket state on focus to the console for debugging.

        socket.onclose = function(){
          console.log('Socket Status: '+socket.readyState+' (Closed)');
          offline();
          $('body').data('update', setTimeout(function() { updateLogs(); }, 1000));
        } 
        // insert the following
        $(window).on("focus.socket", function() {
          console.log('Window is focussed. Socket state: '+socket.readyState);
          if(socket.readyState==3){
            console.log('Socket Status: '+socket.readyState+' (Closed)');
            offline();
            $('body').data('update', setTimeout(function() { updateLogs(); }, 1000)); 
          }
        }); // end 

If you do not see Window is focussed in the console then your nodel.js might be cached in the browser.

@thefennecdeer
Copy link

heya, sorry this took so long, was on a mac version where console.log was broken in safari lol.
but can confirm that I see "Window is focussed. Socket state: 1" printed in console.

@mcartmel
Copy link
Contributor

I have an older iPad here which is working fine and refreshes when you go back to the tab. I think it's dependant on the version of iPad and Safari.

Can you please let me know which versions you've been able to replicate this on?

mcartmel added a commit to mcartmel/nodel that referenced this issue Nov 20, 2023
Proactively disconnect and reconnect websockets when visibility and/or connectivity changes
@thefennecdeer
Copy link

This bug is fixed in iOS 17!

Had another look at this with some newer gen iPads;
The iPads that we first started experiencing this issue with were two 9th-gen iPads on 16.2 (max ios version they will update to).
Also tested two 3rd-gen iPad Pros, one on 16.3 and one of iOS 17.
All three iOS 16 iPads have the bug but the iOS 17 iPad works as expected!

Doing another round of googling; I've found this webkit bug report: https://bugs.webkit.org/show_bug.cgi?id=228296

This issue is being observed only in iPadOS 15 beta, this was working as expected in iPadOS 14.6 and earlier versions

Which explains why this was so elusive to reproduce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cannot reproduce Not being able to reproduce makes it very difficult to solve problem.
Projects
None yet
Development

No branches or pull requests

5 participants