Pagination broken in 2.0.4 #269
Comments
|
Hi - thanks for the report. Could you give me a link to a test case showing the issue please? I'm not seeing it here: https://datatables.net/examples/ajax/simple.html . |
|
Same here. In my case only happens when used in combination with responsive (I tried 3.0.0 and 3.0.2) |
|
Can you give me a link to a page showing the issue so I can look into it? This is 2.0.4 with Responsive: https://datatables.net/extensions/responsive/examples/initialisation/option.html . |
|
And Responsive with Ajax ( https://datatables.net/extensions/responsive/examples/initialisation/ajax.html ), which I might expect to be enabled to see such an error. |
|
The code that triggers the issue is coming from the responsive plugin. The issue doesn't happen on https://datatables.net/extensions/responsive/examples/initialisation/ajax.html because it's not using server side processing, the entire dataset is in See https://jsfiddle.net/bytestream/2vd763xo/17/ for reproducer. Just press "2" in the pagination and you'll see the error. I haven't implemented further AJAX simulation so you won't be able to paginate after that action without seeing unrelated errors... |
|
Ah - thank you! I've commited a change and it is now in the nightly (make sure you use the cache killing query parameter). I've got an example of Responsive with server-side processing here. Could you try the nightly on your own page and if that resolves the issue I'll release 2.0.5 with the fix. |
|
Thanks @AllanJard. It looks good to me. |
|
Apologies, I'm not going to be able to release this today. I'm not 100% certain that my fix is the correct one, or just a patch that covers an underlying issue. It is specifically to do with a function used as a column selector and the data that is passed into it. Quite a narrow condition, but one that Responsive uses. I'll ponder it over night and get a fix (if a different one is needed) and release tomorrow. |
…uld wait for the next draw This relates to #269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now.
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
…y array in `-api row().remove()` - it should wait for the next draw This relates to DataTables/DataTablesSrc#269 and is fairly nuanced - it boils down to the fact that the display array should reflect what is shown in the table, and deleting a value from it will cause an index offset. The other option might be to make the element null, as happens with the master, but that would be a change in type and I'm not certain everything could handle that. The array will regenerate on the next draw, so it is properly in sync with what is drawn now. Sync to source repo @1c48c11ac0168d9598795641b4fc337a2233289e
|
Added one more commit - convinced myself that the one I made yesterday was good, but it also needed a little extra help in how rows are deleted. I'll get 2.0.5 tagged up shortly. |
|
That's 2.0.5 now available. Thanks for flagging this up! |
In v2.0.4 the first page loads OK via AJAX, but when changing page I'm seeing:
That is using the default built-in pagination. It works OK if I revert back to 2.0.3
The problem seems to be in due to the removal of 2.0.3...2.0.4#diff-662ca79630ee6006e2f148471678351039fc22b5a89a0826e379154eaefbf328L103
It now falls through to the
if ( page == 'current' ) {buti = 11anddisplayFiltered = [0,1,2,3,4,5,6,7,8,9]soaends being an array ofundefinedThe text was updated successfully, but these errors were encountered: