Bug #7054
openWTableView can lose synchronization during resize and display "Loading" when data is available
0%
Description
With github wt 4.0.5-31-ga05a7c5d, a WTableView will sometimes display "Loading" although data is available.
It seems that an external change in WTableView size can trigger a scrolled event (via wtResize) after an app has called scrollTo(), but before the scrollTo has been processed by the client. In that case, the server uses the stale information from the scrolled event to update the viewport. When the scrollTo is processed on the client, it may no longer be in sync with the displayed viewport and "Loading" will be displayed. That is, the scrolled position will reflect the application's intent, but the viewport will reflect the old position --- prior to the scrollTo. I believe that this scenario is more likely with websockets enabled.
While there are cases where the issue is consistently reproducible (for a given browser and window size), the attached test program requires some manual interaction:
- Start the program with a wt-config.xml (sample attached) enabling websockets and a max-request-size of 256
- Use a browser to visit the application's URL with a small window (1/4 screen size)
- The application will render a grid of 20 WTableViews positioned at row 1.
- At this point, start increasing the size of the window towards full-screen.
- The application will attempt to update each of the the 20 WTableViews to row 400 in succession.
- One or more WTableViews typically remains in "Loading" state. If not, retry.
Attached is a patch (0002-Fix-WTableView-race-between-scrollTo-and-wtResize.patch) that attempts to address this issue by not processing stale scrolled events. It has been lightly tested, but would benefit from additional review and testing. There are additional notes on the patch.
The patch is designed to be applied on top of the patch included with issue #7043. A version of that patch is attached here as well (0001-Track-count-of-scrollToPending-only-process-last.patch).
NOTE: By disabling the early return that the patch adds to line 1646 of WTableView.C, it is possible to get a log of "stale client resize" attempts without ignoring them. This may be useful in verifying that the patch works as intended.
If I can provide any further information, or if you have trouble reproducing, please let me know.
Files
Updated by Roel Standaert almost 5 years ago
I guess that the whole issue is being caused by the fact that the scrollTo is being delayed by setTimeout(..., 0)?
It seems that the reason for that was to prevent issue #2525. Maybe we can fix that issue more cleanly than this little setTimeout hack.
Updated by Bruce Toll almost 5 years ago
Good catch. I overlooked that setTimeout and it seems reasonable that replacing it could reduce and possibly eliminate this problem.
However, I'm wondering if a stale update could still occur in the presence of a network delay with websockets. That is, the server could update its viewport information and send a scrollTo to the client --- but experience a network delay on the way to the client. Meanwhile, the client could detect a resize and send a scrolled event to the server with stale information.
I'm pretty sure that I could only create this issue with websockets enabled, which may imply that the full duplex connection is the key factor.
Updated by Bruce Toll almost 5 years ago
I was mistaken in my last update. The issue can be reproduced using the test program without web-sockets enabled, so my comment regarding full duplex is incorrect. Unfortunately, the test program is prone to false negatives....
By way of background, the actual application is a widgetset with 6 widgets in html table cells. One of the widgets has a WTableView with an initial scrollTo. All of the widgets appear to get rendered more than once before their sizes stabilize (possibly due to some useStyleSheet calls). In any case, the WTableView initially scrolls to the correct location and looks fine, but then quickly displays "Loading".
Updated by Bruce Toll almost 5 years ago
After some more testing, I believe that you're correct in comment #1 above. Removing the setTimeout appears to fix both the test program and the widgetset application mentioned in my previous comment. Thanks for sorting this out.
Updated by Roel Standaert almost 5 years ago
- Status changed from New to InProgress
- Assignee set to Roel Standaert
Sadly, removing the setTimeout causes issue #2525 to reappear. I think it's just intended as an easy way to make sure the scrollTo happens last, but I think it would probably be better if we can just put that last in the JavaScript being served to the client.