vanderlee / tristate

jQuery standalone tristate (indeterminate) checkbox with pseudo selectors and optional value modification and .val() overwrite. Standalone, so usable for purposes other than list/tree marking.

Home Page:http://vanderlee.github.io/tristate/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

.val() takes too long to update for change-event-listener

andreasnuesslein opened this issue · comments

hey @vanderlee,

first of all: thank you =) i've been looking for exactly this!

however i have one problem:
i have a bunch of input-fields in my form. I do monitor the whole form with

$("#myform").change(function (){ 
  ..do stuff..;
  var x = $('.tristate').val();
  .. more stuff..;
});

x is always one too late, when the change-triggering field is the tristate itself.
i.e. if the tristate is "indeterminate" and i switch it to "unchecked", x will be "indeterminate", and only on the next #myform.change() i will get the correct "unchecked".

any help would be greatly appreciated ⭐

Do you have a jsfiddle example or something similar?
Seems that form change is triggered before checkbox click has been able to change the value.
http://jsfiddle.net/fs7norbL/
Checkbox change is triggered before form change, but I don't know if I might be able to use it, as it would conflict with checkbox click, and I need to use that one.

This is a nasty problem to fix.

Tristate uses checkbox.click to change the value

On chrome, the order of events (http://jsfiddle.net/fs7norbL/1/) is checkbox.change form.change checkbox.click. This means form.change is triggered before tristate has had a chance to handle the checkbox.

On firefix it's checkbox.click, checkbox.change, form.change (so your code should work fine on firefox).

Tristate needs checkbox.click; I can't replace it with checkbox.change, but I could add checkbox.change if I knew these were both caused by the same human interaction.

Trouble is; I don't know how to match up these two events to the same human interaction. There's an event.timestamp which has microseconds, which should be usable for this purpose, but Firefox has a long-standing bug that causes the event.timestamp to be unusable (https://bugzilla.mozilla.org/show_bug.cgi?id=238041). In fact, you can verify this issue in firefox using the above jsfiddle.

I'm looking into different ways of fixing this, but so far I've got nothing. If you have any suggestions, they'd be more than welcome.

I think I've managed to fix it by switching to a .change event (always fired before form.onchange) and creating an alternative fix for old issue #1. I've added a unittest that confirms both the issue and the fix.

Closing it as fixed, but please verify.

Hey @vanderlee ,

omg thank you! =)
I was a bit busy yesterday, so even-though I got the github-mails i couldn't really look into it.
Another night has passed and now you've just fixed it! :)

Thanks again - it works like a charm 👍