Up to a certain amount of total rows, the scrollbar does not reflect the length of the total dataset but, i think, only loaded data rows.
When the scrollbar is put at the bottom, this makes the grid to go to the end of the loaded results, trigger the load of next following rows then move the scrollbar at the center.
This makes impossible to "navigate" quickly at the end of the dataset and, worst in our scenario, makes dgrid.getScrollPosition() and dgrid.scrollTo() totally unreliable. For example, calling many times
dgrid.scrollTo({y: 5000}) makes each times the grid to move to an undeterministic position.
This can be simply reproduced with dgrid/test/OnDemand_promises.html by replacing at line 68:
for (i = 1; i <= 200; i++) {
by
for (i = 1; i <= 800000; i++) {
I hope this will not freeze your computer, because the dstore is memory, this is memory consuming. But this is quickest hack i found to reproduce the bug.
800000 is the value that makes firefox 54 on Linux and Internet Explorer 11 to behave incorrectly for this test. It has been noticed in Firefox 49 in Windows with a value of 1200000. Chrome does not seems to suffer from this bug (or it is more tolerant?).
This issue has been observed with dgrid 1.1.0 and 1.2.0
In our project this value is different (maybe simply because data is different).
Up to a certain amount of total rows, the scrollbar does not reflect the length of the total dataset but, i think, only loaded data rows.
When the scrollbar is put at the bottom, this makes the grid to go to the end of the loaded results, trigger the load of next following rows then move the scrollbar at the center.
This makes impossible to "navigate" quickly at the end of the dataset and, worst in our scenario, makes
dgrid.getScrollPosition()anddgrid.scrollTo()totally unreliable. For example, calling many times dgrid.scrollTo({y: 5000}) makes each times the grid to move to an undeterministic position.This can be simply reproduced with
dgrid/test/OnDemand_promises.htmlby replacing at line 68:by
I hope this will not freeze your computer, because the dstore is memory, this is memory consuming. But this is quickest hack i found to reproduce the bug.
800000 is the value that makes firefox 54 on Linux and Internet Explorer 11 to behave incorrectly for this test. It has been noticed in Firefox 49 in Windows with a value of 1200000. Chrome does not seems to suffer from this bug (or it is more tolerant?).
This issue has been observed with dgrid 1.1.0 and 1.2.0
In our project this value is different (maybe simply because data is different).