* Fix#4135: Plot outputs incorrectly sized inside scaled outputs
CSS zoom property affects el.getBoundingClientRect() but not
el.offsetWidth/Height. When reporting sizes of outputs from
client to server, we need to back out the CSS zoom because
those sizes are used as CSS width/height, which will be
affected by zoom.
(Note that something similar happens with CSS transforms but
we don't have a good way to deal with them)
* Squelch TS error
* `yarn build` (GitHub Actions)
* Add TODO
Co-authored-by: Garrick Aden-Buie <garrick@adenbuie.com>
* Rebuild JS
---------
Co-authored-by: jcheng5 <jcheng5@users.noreply.github.com>
Co-authored-by: Garrick Aden-Buie <garrick@adenbuie.com>
* refactor: Factor out message display from error handler
* feat: Add custom event for sending a client message
* feat: Report binding validity problem via event instead of throwing error
* feat: Don't need to hide shared input/output message
Now that it's not an error, it's safe to report
* refactor: Move `inDevMode()` logic into error console
* refactor: Rename `.error` --> `.event`
* feat: wrap client error message
It's otherwise hard to tell that the error is scrollable
Plus the scrolling is over the whole message rather than the part that overflows
* feat: always send client console messages to browser console as well
* chore: throw if `shiny:client-message` receives an event that isn't CustomEvent
* feat: Handle status in `showShinyClientMessage()`
* Renamed `showMessageInClientConsole()` to `showShinyClientMessage()` to improve clarity
* Added `status` argument to `showShinyClientMessage()` to allow for different message types
* refactor: Don't throw errors for duplicate IDs
Brings dev mode in line with current "prod" behavior,
where errors aren't thrown for duplciates. In both cases
we still get console or client messages.
* refactor: Clean up `status` inside `checkValidity()`
* refactor: Have `checkValidity()` handle emitting the client console event
* Fix#3234: Click handler on scaled image getting clipped
There were two related problems here, both happening in the same scenario:
when an imageOutput with click handlers is showing an image at less than
its natural size (e.g. a 1000x1000 px .png file, being displayed in the
web page at 500x500 due to max-width or for whatever other reason), any
click where the image coordinate (1000x1000) exceeds the display size
(500x500).
In the example above, a user clicks at 300x300 in the 500x500 displayed
image. We call 300x300 the "CSS coordinates". This gets scaled up into
the position in the PNG's own coordinate system, "image coordinates":
in this case, 600x600. Since the 600x600 image coordinate is greater
than the 500x500 CSS coordinate limit, the following issues were
triggered.
1. When imageOutput(click=clickOpts(clip=TRUE)) (the default), these
clicks weren't registering at all. There was code that detected
clicks that were inside the imageOutput but outside the actual image,
but this code didn't take scaling into account.
2. Even with clip=FALSE, the click would be triggered BUT the `x` and `y`
values on the click event were incorrect--they would max out at the
CSS coordinate limit. This because plot and image output divide the
world into "panels" and clicks snap to the nearest panel. In the case
of image outputs, the server doesn't provide any panels, so the
client makes one big panel that covers the whole image--but that code
was erroneously using CSS sizes, not image sizes.
* Update NEWS
* First pass at a proper state machine for managing output progress state
* `yarn build` (GitHub Actions)
* Add useBusyIndicators(), spinnerOptions(), and pulseOptions()
* Bring in new spinner defaults
* Use an actual div instead of a pseudo-element since chromium can't be trusted to show them when animated
* Revert "Use an actual div instead of a pseudo-element since chromium can't be trusted to show them when animated"
This reverts commit 6167c1dfd7.
* Embed animation inside svg (to avoid Chromium bug). Consolidate options into a singular busyIndicatorOptions()
* Add to pkgdown reference
* `devtools::document()` (GitHub Actions)
* `yarn build` (GitHub Actions)
* Bump version
* `yarn build` (GitHub Actions)
* Sync package version (GitHub Actions)
* Apply suggestions from code review
Co-authored-by: Garrick Aden-Buie <garrick@adenbuie.com>
* Update snapshots
* `devtools::document()` (GitHub Actions)
* Address feedback
* Bring in more spinner type options
* fix use of fs
* Code review
* `devtools::document()` (GitHub Actions)
* Sync package version (GitHub Actions)
* Update snapshots
* Fix comments
* Make snapshot consistent cross-platform
* Fix namespace issue
* Reduce specificity of position relative
* Skip snapshot on windows; update news
* Whoops
* Scope spinner customizations to parent element by default
* Update snapshots
* Reorder spinner types
* Set a private random seed in tests
* Better id naming
---------
Co-authored-by: cpsievert <cpsievert@users.noreply.github.com>
Co-authored-by: Garrick Aden-Buie <garrick@adenbuie.com>
* First pass at a proper state machine for managing output progress state
* `yarn build` (GitHub Actions)
* Improved naming
* Include ascii version of diagram (as well as the source file
* Update srcts/src/shiny/outputProgress.ts
Co-authored-by: Joe Cheng <joe@rstudio.com>
* `yarn build` (GitHub Actions)
* Only call showProgress for outputs that have actually changed their recalculating status
* Add some more commentary
---------
Co-authored-by: cpsievert <cpsievert@users.noreply.github.com>
Co-authored-by: Joe Cheng <joe@rstudio.com>
* Add field with devmode status to the initial config object sent over on connection
* Add indicator of "devmode" status to the client via an injected script tag on load. This is modeled after what is done for showcase mode.
* Add logic to flag all duplicated IDs when in devmode
* Only show error console in devmode.
* Remove left-over devmode status in code
* `yarn build` (GitHub Actions)
* Build shiny.js
* `devtools::document()` (GitHub Actions)
* `yarn build` (GitHub Actions)
---------
Co-authored-by: nstrayer <nstrayer@users.noreply.github.com>
Co-authored-by: Winston Chang <winston@posit.co>
Co-authored-by: wch <wch@users.noreply.github.com>
Adds a req(FALSE, cancelOutput="progress") which behaves similarly to
cancelOutput=TRUE, but also keeps the output in .recalculating state
even across flush cycles. This is called "persistent progress" and an
output can leave this state when it is invalidated again and doesn't
call req(FALSE, cancelOutput="progress") during that flush cycle.
This will be useful for implementing long-running tasks that don't
hold up the flush cycle, leaving sessions responsive to do other
tasks.
