You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is currently a bug whereby tables can be empty when switching Tabs
This is caused by a mismatch in how client/server handles enable/disable of viewports.
The client asks server to disable a viewport when user switches tab such that the viewport is no longer visible. This will save bandwidth and processing. The expectation on the client is that it will receive no further messages for that viewport until it asks server to enable the viewport again. It does not clear data from its local cache for this viewport. When user switches tabs again such that the viewport is once again visible , it asks server to enable viewport and it reloads the table from client cache (which was never cleared)
Potential problem here: this cached data might be stale by time user switches back to tab, can we assume server will send fresh data.
What is actually happening is that when client sends disable message, server ACKs this then USUALLY, (but not always), sends a SIZE message of 0 to the client for the disabled VP. This is forcing client to clear its cache, so when Table is re-rendered there is no local data to repopulate it. Although client table sends a range request, because the range has not changed, it isn't sent to server so we end up with no data. Even if we sent range message to server, would it be effective, because server will know it is same range request as before ?
What should be the correct exchange of messages ?
when client sends DISABLE_VP and server responds with DISABLE_VP_SUCCESS, is it correct for server to then send SIZE=0
what is the expected behaviour on client when it sends ENABLE_VP and received ENABLE_VP_SUCCESS ? Does server expect that to be followed by a SET_VP_RANGE message (it will be same as previously sent SET_VP_RANGE, i.e before disable/enable)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There is currently a bug whereby tables can be empty when switching Tabs
This is caused by a mismatch in how client/server handles enable/disable of viewports.
The client asks server to disable a viewport when user switches tab such that the viewport is no longer visible. This will save bandwidth and processing. The expectation on the client is that it will receive no further messages for that viewport until it asks server to enable the viewport again. It does not clear data from its local cache for this viewport. When user switches tabs again such that the viewport is once again visible , it asks server to enable viewport and it reloads the table from client cache (which was never cleared)
Potential problem here: this cached data might be stale by time user switches back to tab, can we assume server will send fresh data.
What is actually happening is that when client sends disable message, server ACKs this then USUALLY, (but not always), sends a SIZE message of 0 to the client for the disabled VP. This is forcing client to clear its cache, so when Table is re-rendered there is no local data to repopulate it. Although client table sends a range request, because the range has not changed, it isn't sent to server so we end up with no data. Even if we sent range message to server, would it be effective, because server will know it is same range request as before ?
What should be the correct exchange of messages ?
when client sends DISABLE_VP and server responds with DISABLE_VP_SUCCESS, is it correct for server to then send SIZE=0
what is the expected behaviour on client when it sends ENABLE_VP and received ENABLE_VP_SUCCESS ? Does server expect that to be followed by a SET_VP_RANGE message (it will be same as previously sent SET_VP_RANGE, i.e before disable/enable)
Beta Was this translation helpful? Give feedback.
All reactions