* webcam: add showVideoSourceDropdown
* webcam: update video device list when adding/removing a video device
* webcam: cleaner changes
* delete extraneous file
* webcam: store sources data in state
* webcam: regather sources after getting access
* webcam: put the source selector next to the buttons
* webcam: put the video source selection on its own row in mobile view
* website: show webcam video source dropdown
* enable webcam features in dev example
* facingMode takes precedence over deviceId, and not needed when specific device is selected
fixes issue where on mobile (iOS) the device selection was ignored due to facingMode being set to 'user'
* Remove “video source” copy, style select, deal with iOS zoom-in issue
Co-authored-by: Tsy-Jon Lau <tlau@parsys.com>
Co-authored-by: Artur Paikin <artur@arturpaikin.com>
The existing word describing drag n drop, while technically correct, is a bit weird when seen on a website.
This commit changes it into a more proper word.
* Explicitly add moment timezone as a dependency and fix timezones for queries and displaying data to be based on user zoom timezone setting
* wip
* Remove async/await to match other providers, add comment to explain to/from conversion from local time to UTC
* Update comment, rename meetingInfo to plural to indicate multiple are retrieved
Unfortunately I can't figure out how to make the dependencies and
versions work out well here.
Instead, this uses a custom slide transition component. It is much more
simple than preact-css-transition-group, which supports animating groups
of components. The `<Slide />` component:
- can only support one element, that either exists or does not exist
- requires that the child element takes a `className` property, that it
passes onto its root element
- only uses `setTimeout()` for when the transition finishes
(in preact-css-transition-group, the `transitionend` event is used,
which is more _accurate_ but less _reliable_)
- hardcodes the transition duration
- hardcodes the transition name
This makes it much more limited. Hopefully the reduced complexity is
worth it.
If we have other transitions in the future, we can copy-paste this
component.
* Fix zoom provider date pagination so that it retrieves the correct start of the next month.
* Add comments to why we are checking dates and try to make initialization of date ranges more readable
* dash: Add support for AVIF images in thumbnails
I added support to load thumbnails when uploading AVIF images, by adding 'avif' to the regex. I also updated the unit test.
Note that support for this is dependant on browser support, and currently only Chrome 85+ and Firefox 77+ support it (Firefox requires flag to be set to allow it)
* Allowed HTML Attributes to be passed via props
This fix still needs some work, as certain attributes could be passed to Uppy or as an HTML attribute, such as target
When this is fixed, this will resolve#2403
* fix: Fixed issues caused by moved dependencies
* Revert "Allowed HTML Attributes to be passed via props"
This reverts commit d7f8076fb3.
* Fixed dependencies
Fixes#2463
There was an issue with the timing of the `_uploadParts()` call. That
function is responsible for _starting_ the upload of multiple parts of
the file. It can start up to `limit` simultaneous uploads, depending on
how many parts are currently uploading.
`_uploadParts()` was called during the completion code for an individual
part. However, the `partsInProgress` state would not be updated until
_after_ the completion code had run. So, inside `_uploadParts()`, it
would see an outdated `partsInProgress` value. Often, this worked OK (if
not optimally) because there would likely be another part in progress,
and once _that_ finished, there would be space again in the
`partsInProgress` value. However, this was _not_ the case if `limit` was
set to 1. In that case, the first part would finish, then we would enter
`_uploadParts()`, and it would see that we were at the limit: it would
not start a new part upload. After, it would never be called again.
This moves the `_uploadParts()` call to _after_ the part upload
completion code. It is now inside `_uploadParts()`, which I think
generally makes the sequencing a bit more clear. Everything related to a
single part upload now has to be complete before `_uploadParts()` runs
again.
* allow webcam to accept constraints as option
* webcam: add typings for `videoConstraints`
* docs: update docs for the new webcam videoConstraints option
* Update website/src/docs/webcam.md
* webcam: prefer videoConstraints.facingMode over facingMode
* webcam: merge in setOptions
* webcam: handle case where constraints cannot be satisfied
Co-authored-by: Kevin Southworth <kevin.southworth@webascender.com>
