states
- jQuery event namespaces were erroneously used to make events more specific,
when instead what we needed were unique custom event names. Namespaces usage
has been fixed, and we only use them now for expedient de-registration.
- A set of new zone state machine transitions have been added and documented
that prevent certain "DnD unhandled transition" console messages on Firefox.
- Firefox 57+ appears not to fire a change event when the `files` field is modified,
which prevented uploads from occuring. This commit triggers a change event manually
and doesn't impact the functioning of other browsers.
- Namespaced events were used improperly in existing code which resulted in "jank"
on Firefox. Namespaces shouldn't have been attached to events generated by the browser.
- The "drop" and "dragleave" handlers are now separate. This fixes a problem
on Firefox where the drop event wasn't reliably changing the state of the input
so it no longer glowed.
This was the product of a long discussion between @wch, @alandipert, @bborgesr
and myself. The conflation of immediate (no throttle/debounce) and non-dedupe
in a single "immediate" flag was deemed unacceptable, because UI controls often
want immediacy but also dedupe. Introducing a second "dedupe" flag would work
but {immediate: false, dedupe: false} doesn't make much sense, and dedupe not
only implies that InputNoResendDecorator should behave differently but also
InputBatchSender (i.e. no deduplication AND no coalescing).
We decided to remove the "immediate" boolean option and replace it with a
string option that would have three possibilities at this time. The only con
to this approach is if anyone is calling onInputChange with immediate:true
today, and I can't imagine anyone is. The immediate flag only has any effect
if the input id that's being set has been put in debounce/throttle mode, and
I don't even think that is documented today, and I'm not even sure it's
possible to do it from custom JS (that's not part of a custom input binding).
We already had an `immediate` input option, which was used to override client side rate
limiting mechanisms (debounce/throttle). This commit extends the semantics of that option
to also mean that duplicate values should not be ignored on the client side.
Previous to this commit, circumventing the client side dedupe logic was not enough. The
server side ReactiveValues object was also subject to deduping. With this commit, the
low-level ReactiveValues class's constructor now has a `dedupe` option, which defaults
to TRUE; the ReactiveValues used for a session's input has it turned to FALSE. I figure
if I had to work this hard to get the client to stop sending duplicates, and the input
values are only expected to ever be updated by the client, then there's really no reason
for server side deduping to be performed for this particular ReactiveValues object.
It would make sense as a future feature to also make deduping optional for user-created
reactiveValues and reactiveVal objects.
* fix appendTab for empty tabsetPanels; use spread operator to avoid having to resort to apply; upgrade grunt.
* revert back to `Math.max.apply(null, existingTabIds) + 1;` there's no browser compatibility issues there
