- Simplified dragHover "plugin" by counting children instead of storing them.
Counting children fixes Firefox 57+ bug (to be found or filed) that causes
text object of input element to produce drag events
- Removed multimethod since it's no longer used anywhere
- Firefox 57+ appears not to trigger 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.
Actually three separate issues addressed. Fixes#2197.
- brush.importOldBrush() was not being called anymore, due to it being
registered as a load handler after the image was already loaded (this
was a very recent regression, less than 24 hours old).
- Each time the brush changes, the plot is redrawn twice. This was
because importing the old brush introduced floating point errors that
led to a slightly different new brush being created.
- Sometimes the image's load event wasn't firing at all. This is due to
behavior in WebKit where assigning an image's src to its existing
value is a no-op.
* wait for image to be loaded in browser before initializing handlers
reverts similar behavior in 3354a47e8a
* default the height and width to the image clientHeight and clientWidth
* use raw image clientWidth and clientHeight instead of container clientWidth and clientHeight
prevents being able to brush on non image areas
Instead of providing alternate defaults for optgroupField,
optgroupLabelField, and optgroupValueField, respect the
selectize instance's settings for those fields.
Fixes#2192. Two problems here:
1. It's not documented but apparently we supported data frames for
choices in updateSelectInput/updateSelectizeInput (it doesn't
appear to work correctly for selectInput/selectizeInput though).
This was used in 023-optgroup-server as well as by the user who
reported #2172.
2. The example in 023-optgroup-server was also counting on the
default value of optgroupLabelField, which (starting post-Shiny
v1.1) was being set to a new default of "group". That now won't
happen unless optgroupField is also blank. I'm less confident
about the ramifications of this change. The selectize docs with
the relevant bits are here:
https://github.com/selectize/selectize.js/blob/master/docs/usage.md#data_searching
This bug is new since v1.1. When results are returned from selectize's
server-side endpoint, iff no results have been selected before, then
the control should be set to either its specified initial value (the
one specified in selectInput/selectizeInput) or, if none was provided
AND the selectize control is multiple=FALSE, then select the first
entry automatically.
That's the desired behavior; the bug was that last part, "select the
first entry automatically", was happening whether results had already
been selected before or not. This was causing merely typing in the
control to cause the value to be changed.
Fixes#2191
* Upgrade FontAwesome to 5.3.1
- Upgrades FontAwesome to a new major (breaking) version, but
is backwards compatible because we include the v4-shims CSS that maps
old names to new.
- This is a step toward full V5 adoption that doesn't require us to
come up with a plan for deprecating V4 icon names.
- Details: https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4
- Related to #2156 and #1966
* Improvements to icon
- Clarify in docs that fontawesome V5 icons accessible with V4-style names
- Make icons browseable: icon('address-book') will now open the Viewer
pane of RStudio IDE so that icons can be experimented with more easily.
* Update LICENSE with CC for FontAwesome .svgs
* Update NEWS
* dehighlight dates outside of range for datepicker
* override color in shiny.css instead of package css
* refactored css styling to use specific references instead of !important
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.
This was introduced by some changes to shinyapp.js that were necessary
before async outputs and sync outputs were held/flushed together. Now
that async/sync outputs are held/flushed together, these changes are
not necessary and removing them fixes the problem.
The test app is in shiny-examples/205-async-req. I also moved a test
app from manualtests/async/download.R to shiny-examples/204-async-download.
