Checkbox issues

[ghost]

I'm using the header below for the column my checkboxes (and select all checkbox) reside, but there is still a sorting function on this column (sorting by checkboxes checked doesn't really make sense.) Can you help me to remove that?

        12: {
            sorter: 'checkbox'
        }

Second issue: If I select all, go to another page of the site, then return to the page with tablesorter on it, the checkbox for select all remains checked. Any idea of how to get rid of that?

[Mottie]

Hi @aetna-wsa!

Add a "sorter-false" to the header cell to prevent sorting.

As for the checkboxes remaining checked, that is a browser issue; please see #996 for more details.

[ghost]

Thanks for the help. I'm assuming when you say "add a 'sorter-false'" you man to the th class. This is what I have, and it is still sorting:

                        <th class="filter-false sorter-false" style="text-align:center;">

As for the browser issue, it appears that is a Chrome issue, but I'm developing for IE.

[Mottie]

Yes, add "sorter-false" as a class name.

So you're seeing the same problem in IE?

[ghost]

Right, but after naming the class as shown above, it is still sorting (undesired behavior.) T

Yes, the problem mentioned, I have in IE.

[ghost]

I looked at the rendered code in Firefox, and the class "sorter-false" is being removed by the script. I'm thinking this has to do with the fact that the column is marked as sorter: 'checkbox' (since that would not equate to false, so it is being overridden?)

[Mottie]

Try adding data-sorter="false" to the header cell instead.

[ghost]

No, all that did was make it so that the global checkbox at the top never gets checked. Worse, though, is that clicking it again has no affect on the children checkboxes.

[ghost]

Just to clarify -- I am getting no sort arrows when the page is loading, now, but once clicking on the global checkbox, it starts sorting for each subsequent click.

[Mottie]

I recently noticed an issue with the parsers not being properly detected when a header has multiple rows with a colspan across all rows. If you do have this situation, add "tablesorter-ignoreRow" (set by the cssIgnoreRow option) to those thead rows (TR's only) that are not involved with sorting.

If that isn't the case, then please modify this demo (the header and 1-2 rows should be enough) to help me troubleshoot the problem.

[ghost]

Okay, take a look: https://jsfiddle.net/8y28svef/6/

Now, the problem is not showing here. (I can't test in IE since it does not support jsfiddle, but the problem was in firefox, too) but the only difference (that I can see) is that the parser-input file is NOT being referenced here (it wasn't in your original fiddle.)

Any idea why this would be? I copied and pasted almost exactly, except for files to be included.

On a side note: if you click to view the next five records, you'll see the problem with the checkbox already checked as mentioned before.

[ghost]

Did you have a chance to review? There are not multiple rows with colspans. I'm at a loss as to what I should do now, if you can help.

[Mottie]

Sorry, I have had many distractions. I just looked at the demo and I wonder... why set the checkbox column to have a "checkbox" parser when you don't want to sort the column?

I tested the jsFiddle in Chrome & Firefox (use http:// not https:// to get the demo to work) and the problem you mention with the select all checkbox is because there is no logic added to remove the check.

I did include this logic when I added the select all checkbox code into the parser-input-select.js file. All you need to do is add a checkbox to the header and it activates. There are also two utility options named checkboxClass and checkboxVisible which can be set to alter the behavior. I tried updating your demo and it isn't behaving as expected - the checkbox clears immediately... oddly it works perfectly in this demo which I made for issue #971.

[ghost]

I thought that was what was required - I didn't notice before that your demo sorts by that header. You have the following in that code:
headers: {
0: { sorter: 'checkbox' }
I'll try the methods you stated and see if I have any better luck. Thanks!

[ghost]

Sadly, I'm running out of time and don't know what to do at this point. Yes, my demo has the checkbox clear immediately on clicking -- then clicking again does the same time, only that time it does not "uncheck" all the other checkboxes. Do you have any idea where I could start to figure out this issue? I've several more defects I have to work on, but this is a big one!

[ghost]

It has something to do with the parser-input-select.js file, since when I comment out that line (including the file) the checkbox works normally again (although, of course, it is not 'selecting all' as expected.)

[Mottie]

Hi, yes, actually I found the issue... the checkbox parser adds event listeners to the checkbox and add a class name to the row. The header checkbox code looks for that class name to find rows with checkboxes.

Since the checkbox parser is disabled, no class names are being added and thus the header checkbox does not find any class names and assumes there are no checked checkboxes. I'm working on a fix. Please be patient.

[Mottie]

Ok, the fix is in the master branch.

[ghost]

Thank you so much! We're almost there, now. The checkbox (for select all) is still coming up as checked when the page loads. Is there a quick jquery call I can make to get that to go away? I've tried (and failed) with the following:
$('#GlobalCheckBox').prop('checked',false);

[Mottie]

Let the code inside of parser-input-select.js do all the work... don't add code to change the check.

[ghost]

I tried. It isn't working (it always starts with that checkbox checked.) Also, I found a new problem: After filtering on any one column (or multiple) the select all checkbox fails to have any effect if clicked on or off, until the page is refreshed.

[ghost]

Actually, in the last instance, it also will no longer allow for sorting after filtering.

[Mottie]

Sadly, I've run out of time to look at stuff this morning. I'll try to look again later tonight.

Please modify this demo to show the behavior you are describing to make it easier for me to troubleshoot the issue.

[ghost]

I understand, and I'll look at the demo to see what is going on. At first glance there are no changes in the respective pages. What is happening is that as soon as I filter on any column, all other functions (namely the sorting and checkbox selections) is failing. Do you know if an issue like this has come up before?

[ghost]

I've tried and cannot modify the demo in any way to more accurately reflect what is going on locally. I removed all potentially conflicting code on my side (to more accurately reflect exactly what is happening on the JS side (as in the fiddle) -- css I'm sure doesn't matter, and html is identical. I still cannot reproduce the issue in the fiddle, but it is still happening for me locally. I'm not sure what else I can do on my end.

[Mottie]

This issue should now be solved...

---

For future reference: The problem turned out to be the code in the parser-input-select.js file which binds to all tables and listens for a "tablesorter-initialized" or "updateComplete" event. Once that happens, the code added more bindings for form element interactions (focus, blur, change, keyup, etc).

So, when the core plugin "triggered" a "tablesorter-initialized" on the table, it bubbled up through the table that was being used for layout. So now the layout table had event listeners and fired whenever the filter inputs changed... basically breaking a bunch of stuff since the filter inputs aren't contained in the same table's tbody.

The fix involved changing all trigger functions on the main table into triggerHandler which does not bubble up the DOM (87a10d6).

Also, fixed was an issue in IE8 where the checkbox code needed to return true before IE8 would process the change (b84b38e).

[ghost]

Rob -

I'm using the newest version of parser-input-select and this problem has reverted to this ugly behavior again. I've tried on IE11 and Firefox - each time the page is loaded, the global checkbox is checked by default when initialized.

[Mottie]

There have been a few changes to the parser-input-select file since this issue. See:

• Value changing on checkboxes in Chrome #1125
• Checkboxes not changing based on global "select all" checkbox #1199

Please test the file from v2.25.8 to see if the problem disappears.

[ghost]

I Have already updated to v2.25.9

[ghost]

Using v2.25.9 - 2.25.8 is no longer available. Still failing after updating to latest version.

[Mottie]

https://github.com/Mottie/tablesorter/releases/tag/v2.25.8

[ghost]

That release did not have the newer code (after it was fixed.) The version in v2.25.8 of parser-input-select.min.js is 2.25.2 (older than the fixed version which was later that April, and doesn't work.) So I tracked down the April version (2.25.9) and that version is TOO new, also doesn't work.

[ghost]

Hi, Rob - anything on this one, yet? I know it was fixed before, I just don't know what version to go back to. Thanks.

[Mottie]

I haven't done anything with this issue because I'm not sure what the issue is anymore - I don't have an "real" version of IE11 to test the issue on.

While using this demo in Firefox and Edge (IE11 compatibility mode), the header checkbox updates as I would expect in both checking and unchecking the visible checkboxes. When toggling the visible checkboxes within the table, the header checkbox set to checked, unchecked and indeterminate as expected.

If this is truly a problem only in IE11, I'll need to either borrow an old laptop from a friend, or wipe my laptop and install WIndows 8.1 on it to test it. Either way, ugh.

[ghost]

I apologize for the confusion - the issue is present in Firefox as well. (BTW, I would never ask you to have to wipe your laptop!) On December 4th, you wrote the following, indicating it was fixed (and it was) it seems, though that it is back.

For future reference: The problem turned out to be the code in the parser-input-select.js file which binds to all tables and listens for a "tablesorter-initialized" or "updateComplete" event. Once that happens, the code added more bindings for form element interactions (focus, blur, change, keyup, etc).

So, when the core plugin "triggered" a "tablesorter-initialized" on the table, it bubbled up through the table that was being used for layout. So now the layout table had event listeners and fired whenever the filter inputs changed... basically breaking a bunch of stuff since the filter inputs aren't contained in the same table's tbody.

The fix involved changing all trigger functions on the main table into triggerHandler which does not bubble up the DOM (87a10d6).

Also, fixed was an issue in IE8 where the checkbox code needed to return true before IE8 would process the change (b84b38e).

[Mottie]

It can't be the same problem. The code is still using triggerHandler and IE8 isn't the issue here.

Please describe or screenshot the issue you are seeing... saying "fail" doesn't help.

[ghost]

Screenshot below (from Firefox) -- not sure how this would help, though.

[ghost]

I'm sorry - I didn't click on your screenshot link until now. Here is the GIF:

[Herst]

@Mottie: If you have Edge then you will also have IE11, those are independent.

[Mottie]

@Herst Derp... LOL, I guess I never paid attention to that... it's not like I even use Edge more than once a month or so to test stuff.

In any case, I still can't reproduce the issue. I wonder if it is because the table is hidden on initialization? I'll mess around with it and see.

[Mottie]

Ok, it should be all fixed now - demo.

@aetna-wsa, next time please share more details about how to reproduce the issue... the animated screenshot gave me all the clues I needed! If I would have known that the table was initially hidden, I could have duplicated the problem in Chrome and had the problem fixed even faster.

[ghost]

Heh.. I'll try harder to be as specific as possible in the future. I never considered this could have been related, but that shows how much I know! That is a cool little application you showed me--it will definitely come in useful in the future. Thanks for the help - it worked perfectly. 💯

(BTW, I don't know if it matters a lot to you, but the date and version are still the older version's.)

[Mottie]

Thanks! I'll update that before the next release. I forget sometimes, but I always try to double check all the changed files before I tag the release.