`ajax.reload(null, false)` does not always maintain paging. I have your bug.

`ajax.reload(null, false)` does not always maintain paging. I have your bug.

alexpersonalexperson Posts: 3Questions: 0Answers: 0
edited February 11 in Free community support

tl;dr I've debugged datatables.js and found the bug to this issue, please read bellow.

This is regarding ajax.reload(null, false) still resetting paging when I EXPLICITLY tell it not to. I understand this works in plenty of JS-fiddle examples, but it doesn't work for me and doesn't work all the time. I suspect it worked in a small example because a race-condition happened in your favor.

In version 1.10.18:

BUG NUMBER ONE:

Around line 7634, _api_register is doing:

    ```_api_register( 'ajax.reload()', function ( callback, resetPaging ) {
            return this.iterator( 'table', function (settings) {
                    __reload( settings, resetPaging===false, callback );
            } );  
    } );```

This is called again on line 7557:

    ```var __reload = function ( settings, holdPosition, callback ) {
            // Use the draw event to trigger a callback
            if ( callback ) {
                    var api = new _Api( settings );

                    api.one( 'draw', function () {
                            callback( api.ajax.json() );
                    } );  
            }```

And the value holdPosition is not carried through. I console logged the value in the part 7634 and confirmed the value was false, however, when 7557 is called, the value is not false. Because of this, resetPaging aka holdPosition (great naming consistency btw, all you have to do is s/resetPaging/holdPosition/g to refactor) is not carried through.

This causes the bug ajax.reload(null, false) to break! It doesn't work!

I don't know what this.itterator is in this whole codebase and I don't want to know. I also don't know why that function has a parameter that has a comparison operator, but hey, I'm not a Javascript guy!

BUG NUMBER TWO:

In __reload, depending on the _fnDataSource( settings ) == 'ssp', some steps are done and finally _fnReDraw( settings, holdPosition ); is called, however, when the ssp condition is false, _fnReDraw( settings, holdPosition ); gets called TWICE! Why it get's called twice? I don't know! You tell me!

In the first time it's the holdPosition is at least passed through from __reload to _fnDataSource (even though it's not passed through from _api_register to __reload. But if it's manually set there, it will at least carry through to _fnDataSource. This is fine and dandy, however, something else is calling that function again, this time without the same value for hold parameter.

My guess as to why this breaks is a race-condition, but from my debugging, I've proved the value isn't even passed as it was intended. My guess is that your small testing case JUST HAPPENED to work because the race-condition went in your favor.

I've been able to solve this bug myself by taking the non-minified version and hard-coding in that holdPosition variable, never letting settings._iDisplayStart = 0; to be called, but the code is wrong and configuration is shaky at best. I personally don't really like the code base.

CONCLUSION:

I don't know about datatables (whatever this.itterator is doing) to make a pull-request, nor know if anybody would use it anyway. Someone who regularly maintains this please fix this bug.

Replies

  • allanallan Posts: 50,277Questions: 1Answers: 7,469 Site admin

    Hi,

    Thanks for your bug report. If you could show the issue with a test case, that would be greatly appreciated. As you mentioned, it works in other examples and I've just created this example and its also in our unit tests, so at the moment I don't know how to reproduce the issue you are seeing. If you can link to a page showing the issue, then that would allow be to debug it and fix the issue identified.

    when the ssp condition is false, _fnReDraw( settings, holdPosition ); gets called TWICE!

    I'm not seeing that I'm afraid. Inspecting the code I see it being called once. Using a break point in Chrome's inspector confirms this.

    If you could give me an indication of how to reproduce that error as well, that would be great.

    Thanks,
    Allan

  • DevilDogDevilDog Posts: 1Questions: 0Answers: 0

    I have the same bug. Even when I set resetPaging to true, it is not being carried to holdPosition which is still false. And also about the naming, aren't resetPaging and holdPosition opposites?

  • tangerinetangerine Posts: 2,354Questions: 18Answers: 260

    See Allan's post of Feb 12th.

Sign In or Register to comment.