Initial invocation of ajax call always has length set to 9 - 1.10.18 differs from 1.10.15

davedargo

I'm upgrading from 1.10.15 to 1.10.18 and am having difficulty with the ajax requests I'm receiving on the server side. My ajax requests, by the way, are via my own ajax function.

I use scrolling for my tables and with 1.10.15 I always receive a length of 99 for the data requests. With 1.10.18, the initial request is always a length of 9 and subsequent invocations are 99.

On my page I have multiple tables hidden by tabs and the default tab's table is automatically loaded when the page is loaded. With 1.10.18, subsequent ajax calls won't be made to load additional data until I've scrolled through a fair amount of blank space as if DataTables thinks those rows had been loaded. Subsequent calls do, however, request a length of 99 and all scrolling works as expected at that point.

It doesn't seem to matter how the subsequent calls are requested, they always request 99 rows (which is appropriate).

If immediately after completing the first load of the table I issue a DataTable().ajax.reload(), having done nothing else, the load request issues a length of 99.

If after completing the first load of the table I request a different table to be loaded its initial load request is with a length of 99.

If I change the page to have a different table be the first to initially load by setting a different default tab, its initial request is for a length of 9 and subsequent requests issue a length of 99.

1.10.15 always issues a length of 99 for these tables. 1.10.18 issues a length of 9 for the first request and 99 for subsequent.

I've attempted setting pageLength to no avail to try and influence the first load.

The table itself will fit 11 rows. When simply scrolling to request additional rows the ajax call isn't issued until I scroll to about the 50th position. After that scrolling and load requests function as expected.

Any clues where I can look next?

Thanks

allan

Are you using Scroller? Have you also updated Scroller?

Can you link to a page showing the issue please?

Allan

davedargo

Yes, I am using scroller. All packages were updated and scroller is currently at 2.0.0.

I have travel scheduled this week and will attempt to create a test case upon my return this weekend.

I have no doubt it's something simple I'm either doing or failing to do so it will be interesting to see if I can capture a test case. If not, I will attempt to create a subset of the live system to give you access.

Thanks

allan

Thanks. It might very well not be something you are doing - Scroller is a tricky beast and there might well be an issue.

Allan

davedargo

Occasionally, the column headers do not align with the columns on the initial draw. In this case, subsequent loads of the table also send a length of 9. Previously I had been forcing a re-draw after the initial load to fix the column headers.

Assuming the column headers do align on the initial draw then the following observations are correct (perhaps this is expected behavior but it does seem to be at the heart of the issue):

• In scroller's construct on the initial call to the measure function the dom.scroller.clientHeight is 0 and heights.viewport is also 0 causing it to use the css('max-height') value from this.dom.scroller which also happens to be 0. This sets the heights.viewport to 0.

On the next call to measure, initiated by the dt.on( 'init.scroller' call defined in the constructor, the clientHeight is 400 which causes the heights.viewport to be set to 400 which results in correct draw and scrolling behavior on subsequent calls to load the data.

If I force the initial heights.viewport to 400 (which is my scrollY value) in measure in the initial call then I get the expected loading parameter of length:99 rather than 9. I did this simply by replacing:

heights.viewport = this._parseHeight($(this.dom.scroller).css('max-height'));

with

heights.viewport = 400;

This also forces it to work whether the column headings align or not.

I don't want to send you down a rabbit-hole and I will attempt to create a test case this weekend. I just wanted to provide this information in case it has meaning to you.

allan

What you have said is more or less what I was suspecting might be the case. If you remove the scrollCollapse option (which I guess you are using), it should be 400 at the start.

Allan

davedargo

This is interesting. I was not specifying scrollCollapse so it was defaulting to false.

Paradoxically, setting scrollCollapse: true resolves the problem for me.

The computations done in the initial calls in the constructor are now correctly returned causing the length parameter to be set as expected.

After looking at your suggestion I had a further look at the calls made to measure in the constructor.

With scrollCollapse defaulting to false, the initial call to _parseHeight has a cssHeight of 'none' and I get the undesired behavior of the initial length set to 9.

With scrollCollapse set to true, the initial call to _parseHeight has a cssHeight of 400, which matches my scrollY parameter. This gives me the desired behavior of the initial length set to 99.

You have solved my issue, thank you for that.

I hope some of the information provided here will either confirm that you have expected behavior or give you a lead to correcting the behavior.