BUG REPORT: ListGrid scroll to top on updateCaches(), EDGE only

[pci-abarbaro]

We have reproduced this on SGWT 12 2019-01-07.

On EDGE you should scroll down on the grid, edit a row, and onEditorExit the grid will scroll to the top. This does not happen in Chrome.

[pci-abarbaro]

The attachment didn't attach, here there is.

[Isomorphic]

We do see the issue with MS Edge that you mention, once we fix your sample to set the sequence field as the primary key. In this case, the browser is initiating a scroll to the top, not our Framework, and we are doing nothing to trigger it. It's just a weird browser bug. We are looking into a possible workaround, but it may not be perfect, and if all we can do is reverse the unexpected scroll it may create visible jitter.

However, if the code you provided actually represents what your app is doing and isn't designed solely to reproduce the MS Edge bug, then there are some problems to resolve which might allow your app to avoid the logic path that exposes the reported bug in the first place.

First, in your repro code, if one makes an edit to the text field of a record in the grid, then it automatically updates the DS when you commit the edit (by hitting return, say), as you can see in the RPC tab of the developer console. So, the entire editorExitHandler logic in the sample code is superfluous. That is, the ResultSet cache is ultimately updated by a reply from the client-only DS.

Second, you're not saving the correct record to the cache in the editorExitHandler in the sample. The record in the event is the unaltered record, without the change from the edit. If you want to apply the edited record to the cache manually, you'll need to take the new value from the event, merge it into the record by applying it to the correct field, and then use that modified record to update the cache. The reason things seem to work with that bug present is that it's masked by the first bug. That is, you're putting the unedited value into the cache, but then the DS update reply comes back with the (correct) edited record and that overwrites the cache contents.

It may be possible to avoid the logic flow triggering the scroll jump in your app itself using a SmartGwtTimer, but before getting into that, we'd like to sort out the above issues.

[lpolvani]

Been a while, is there any update on this issue?

[Isomorphic]

A fix for this was applied in late February for SGWT/SC 12.0+, but we were waiting for your answers to our questions about your sample code before following up again in this thread since it seemed like other problems were present that we wanted to make sure were resolved. If you pick up a current nightly patch build, it should have the fix.

[lpolvani]

Thank you, will test and get back to you