Calling draw() on one datatable appears to be affecting other unrelated datatables

Calling draw() on one datatable appears to be affecting other unrelated datatables

bg7bg7 Posts: 44Questions: 6Answers: 0

Link to test case:
http://live.datatables.net/noyidohu/3/edit

Description of problem:
In our application we have multiple DataTables instances. We recently tried to upgrade from an older version of DataTables and the Editor and ran into problems with calling draw() on one DataTable instance affecting unrelated DataTables instances.

Our current versions are:
DataTables 1.10.18, Editor 1.7.4, Buttons 1.5.2, Select 1.2.6

We're trying to upgrade to the current versions:
DataTables 1.10.23, Editor 1.9.6, Buttons 1.6.5, Select 1.3.1

In the linked example code there are two DataTables. The first one is just a simple DataTables instance. The second is a DataTable and the related Editor. The second DataTable has a single date field that is of type datetime. The example code has an interval calling draw() on the first of the two DataTables every five seconds. In order to actually see the problem you'll have to open the live preview into its own window with the arrow button at the top right of the output panel. For some reason it behaves differently as a panel (possibly also a bug?). Once you do that, click the "New" button for the second DataTable. By default it will set the focus to the only field (the date) which will open the calendar widget. Once the calendar widget appears, the next time that draw() is called on the first table (you can watch the log for that in the browser debug console) the calendar widget will disappear. Click back in the date field and it will disappear again the next time draw is called on the first (unrelated) table. In our application we have a DataTable that is always shown that updates on a two second interval. This makes using the calendar widget nearly impossible as it is constantly disappearing as we're trying to select a date.

All that said, if you comment out this line in the first DataTable configuration:
scrollY: 200,
then the problem goes away. We do however need to set that flag though so removing it won't work for us.

Is there a way to keep the two DataTables from interacting? Is this a bug? Are we doing something wrong? We'd really like to upgrade and make use of some of the newer DataTables features and are hoping there's a fix or workaround for this issue.

Thanks.

This question has accepted answers - jump to:

Answers

  • allanallan Posts: 63,214Questions: 1Answers: 10,415 Site admin

    What is happening here is actually specific to the date picker input. It has an event listener on the ‘resize’ and ‘scroll’ events on the page that will automatically hide it when that event happens. It just so happens that your drawing of the DataTable is causing that to happen. The reason it auto hides is that it is relatively easy for the date picker to be mispositioned when the document moves around it.

    We perhaps need to disable or remove that behaviour. I can show you the lines in Editor to comment out for the time being if you like?

    Allan

  • bg7bg7 Posts: 44Questions: 6Answers: 0

    Allan,

    That makes sense. If you can point me in the right direction to comment it out that'd be great!

    I'd definitely vote for that behavior to be removed or at least to be optional via some sort of a flag. I'd prefer not to have to go in and patch every release from here on (I'd be worried I'd eventually forget). By the way, what's the best way to minify the patched code?

    We use DataTables in a bunch of places in our application and one of them is essentially an activity log updating every two seconds. As a result that makes the date picker input effectively unusable everywhere we need it. For what it's worth, this behavior does seem to have changed since the release we're currently using as it's not a problem there.

    As an aside, we've been using DataTables for a long time and it's fantastic. We're big fans. Thanks so much for all the work you've done.

    Ben

  • allanallan Posts: 63,214Questions: 1Answers: 10,415 Site admin
    Answer ✓

    Hi Ben,

    You are right, this is something that was changed relatively recently. I'll look at reverting it and revisiting why I made that change in the first place!

    In the meantime, in the Editor code search for this block:

            $(window).on( 'scroll.'+namespace+' resize.'+namespace, function () {
                that._hide();
            } );
    
            $('div.DTE_Body_Content').on( 'scroll.'+namespace, function () {
                that._hide();
            } );
    
            $('div.dataTables_scrollBody').on( 'scroll.'+namespace, function () {
                that._hide();
            } );
    

    Change the that._hide(); call to be that._position(); in all three cases and that will reposition the picker rather than hiding it.

    Regards,
    Allan

    p.s. Thanks for your kind words :)

  • allanallan Posts: 63,214Questions: 1Answers: 10,415 Site admin
    Answer ✓

    By the way, what's the best way to minify the patched code?

    I forgot to reply to this point. We use Closure Compiler, but you could use UglifyJS or any other minifier. It shouldn't really matter.

    Allan

This discussion has been closed.