* ✨ Add svg-attrs casing fix migration
* ⚡ Optimize set-shape-svg-attrs by removing redundant operations
- Remove backward compatibility for kebab-case SVG attribute keys
(fill-rule, stroke-linecap, stroke-linejoin) since svg-attrs are
already normalized to camelCase by the attrs->props migration.
- Remove unnecessary select-keys filtering and intermediate map
construction (dissoc :style + merge style).
- Directly extract values from style and attrs using or, avoiding
any intermediate map allocation.
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
* 🐛 Filter non-http(s) URLs in upload-images to prevent invalid calls
Skip upload for image items that are not data URIs and do not have
an http:// or https:// URL, avoiding unnecessary RPC calls with
invalid URLs to create-file-media-object-from-url.
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
---------
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
The workspace Actions history panel previously showed the operation
icon and a one-line message for each undo entry with no indication
of when the action happened, any stable way to refer to it, or who
made the change. The reporter of issue #7660 (and @Takhoffman's
follow-up comment) asked for a git-like display: `<hash> · <time> by
<name>`.
This change stamps each undo entry with its creation timestamp and
author at the moment it lands on the undo stack and surfaces three
extra pieces of information in the history sidebar:
- A short 7-character identifier derived from the entry's existing
`:undo-group` UUID. Hovering shows the full UUID.
- A relative timestamp (e.g. `just now`, `5 minutes ago`, `2 hours
ago`, `3 days ago`) rendered via `app.common.time/timeago` so it
matches the formatting already used for comments and the dashboard.
- The display name of the profile that created the entry, rendered
as `by <Name>` in the same metadata row.
The undo stack is client-side per profile, so every entry is always
the current user; the author is stored on the entry anyway so the UI
does not need to reach into profile state while rendering and so the
data stays correct if the stack shape ever changes.
Changes at a glance:
- `data/workspace/undo.cljs`: extend `schema:undo-entry` with an
optional `:timestamp` and `:by`; new `profile-display-name` helper
that falls back from full name to email to nil; `stamp-entry` now
takes state and fills in both fields on entries that do not
already carry them. Pre-stamped entries (e.g. coming out of an
accumulated transaction) keep their original values.
- `ui/workspace/sidebar/history.cljs`: propagate `:timestamp`,
`:undo-group`, and `:by` through `parse-entries`; add `short-id`
helper; render the metadata row in `history-entry` using
`app.common.time/timeago` against `:timestamp`; skip the author
span entirely when `:by` is nil.
- `ui/workspace/sidebar/history.scss`: styling for the new metadata
row (monospace hash, muted separator, truncated time/author).
- `translations/en.po`: 1 new string for `by %s`.
Existing undo entries created before this change have neither
timestamp nor author; the UI is defensive about both, so old entries
simply render with whatever data they have (and often the plain
title on its own).
Github #7660
Signed-off-by: FairyPigDev <luislee3108@gmail.com>
Signed-off-by: FairyPiggyDev <luislee3108@gmail.com>
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
* 🐛 Reject clipboard helpers gracefully on insecure origins
Closes#6514. Resolves the user-visible crash originally reported
in #4478.
`app.util.clipboard/to-clipboard` and `to-clipboard-promise` called
`(unchecked-get js/navigator "clipboard")` and then immediately
invoked `.writeText` / `.write` on the result, with no guard for the
case where `navigator.clipboard` is `undefined`. The W3C Clipboard
API spec requires a "secure context" (HTTPS or localhost), so a
Penpot instance served over plain HTTP - which the SSDP/LAN
self-hosted setup in #4478 was - throws
TypeError: Cannot read properties of undefined (reading 'writeText')
synchronously the moment the user clicks any copy button. The error
escapes the consuming function before any error-handling rx/of arm
runs, so the whole UI ends up on the error screen instead of just
the affected control showing a "could not copy" message.
A third helper (`to-clipboard-multi`) already guards `clipboard` and
`clipboard.write`, but if both are missing it silently returns nil
which is also surprising for callers expecting a Promise.
## Fix
Add a small `get-clipboard` accessor and an `unavailable-error`
factory that returns `Promise.reject(Error(...))` with a clear
message ("Clipboard API is unavailable. This usually happens when
the page is served over plain HTTP; serve Penpot over HTTPS to
enable copy-to-clipboard."). Wire all three helpers through the
same defensive contract:
- `to-clipboard` - return the rejected Promise when
`navigator.clipboard.writeText` is missing.
- `to-clipboard-promise` - return the rejected Promise when
`navigator.clipboard.write` is missing.
- `to-clipboard-multi` - convert the existing `if` into a `cond`
with three branches: prefer `clipboard.write` for true multi-MIME
output, fall through to `writeText` with the text/plain payload
when only the legacy text path is available, and finally reject
with the unavailable error when neither path exists. Previously
the no-API case fell off the `when-let` and silently returned
nil.
The contract is now consistent: every helper either resolves or
rejects a Promise, never throws synchronously, and never returns
nil. Callers (which are already structured around rx streams that
call `rx/from` on the helper's return value) can chain `.catch` /
`rx/catch` to surface a status-bar message instead of crashing.
The two stale `;; FIXME` comments on `to-clipboard` (rename to
`write-text`) and `to-clipboard-promise` (this API is very confuse)
are removed - the rename remains an open follow-up across 13+ call
sites and is intentionally out of scope, but the API is no longer
"confuse" once the contract is documented and uniform.
CHANGES.md entry added under the 2.17.0 Bugs-fixed section
describing the user-visible behaviour change.
* 🐛 Reject paste-from-navigator gracefully on insecure origins
Symmetric companion to the to-clipboard / to-clipboard-promise /
to-clipboard-multi guards added earlier in this PR. The paste path
went through fromNavigator (frontend/src/app/util/clipboard.js) which
called `navigator.clipboard.read()` with no nil-check; on insecure
origins (plain HTTP / non-localhost) this raised an opaque
`TypeError: Cannot read properties of undefined (reading 'read')` and
the workspace surfaced a generic 'Something wrong has happened' toast
instead of the descriptive 'serve Penpot over HTTPS …' message users
get for the copy direction.
Mirror the get-clipboard pattern from clipboard.cljs:
- Read `navigator.clipboard` once into a local.
- If it's missing the `.read` method, throw a descriptive Error that
matches the wording the copy direction already uses (only the verb
swaps: 'paste-from-clipboard' instead of 'copy-to-clipboard').
- Otherwise, dispatch through the local handle.
The existing app.util.clipboard/from-navigator (clipboard.cljs:32)
already wraps impl/fromNavigator in rx/from, so a rejected Promise
from the async function propagates as an rx error event. Existing
callers that subscribe with .catch / on-error see the structured
Error and surface the toast, identical to how to-clipboard's
unavailable-error already flows.
Repro (matches niwinz's reproduction in the PR comment):
Object.defineProperty(navigator, 'clipboard', { value: undefined });
// … then attempt a paste action in the workspace …
Before: TypeError in console + 'Something wrong has happened' toast.
After: descriptive Error caught by the rx subscription and rendered
through the existing unavailable-Clipboard-API surface.
Refs #6514, #4478
* 🐛 Show user-facing toast when clipboard API is unavailable
Niwinz's review on penpot#9188 caught that the rejected Promise from
to-clipboard / to-clipboard-promise / to-clipboard-multi /
fromNavigator now surfaces the correct error to the console, but the
workspace UI still falls through to the generic "Something wrong has
happened" toast because the on-clipboard-permission-error and the
paste error-handler in paste-from-clipboard only branched on
clipboard-permission-error?.
Apply the patch he suggested in the review:
- Add clipboard-unavailable-error? predicate that matches the
Promise.reject(Error("Clipboard API is unavailable. ...")) thrown
by the get-clipboard / unavailable-error helpers added earlier in
this PR. Uses str/starts-with? on the message prefix so the
predicate stays stable even if the trailing "serve Penpot over
HTTPS ..." advice text is reworded later.
- Convert on-clipboard-permission-error from `if` to `cond` and add
a third arm that fires errors.clipboard-api-unavailable as a
warning toast.
- Add the same arm in the second cond block inside
paste-from-clipboard, before the :not-implemented and :else arms.
- Add the matching errors.clipboard-api-unavailable entry to
frontend/translations/en.po with the wording niwinz suggested:
"Clipboard API is unavailable. Serve Penpot over HTTPS to enable
clipboard access".
Refs penpot#9188 review.
---------
Signed-off-by: Andrey Antukh <niwi@niwi.nz>
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
* ✨ Implement asset re-uploading to wasm
* ✨ Show toast instead of error screen when webgl context is lost
* 🎉 Recover context after webgl context restored event
* 🎉 Set Read-only mode when the context has been lost
* ✨ Disable scroll & zoom when context loss
* ✨ Fix stale reload payload
* ✨ Use existing debounce util to take screenshots
* ✨ Implement design / ux specs
* ✨ Fix playwright test by looking for toast, not error page
Closing the fill dialog while an image-fill upload is still in flight
(or while a gradient is mid-edit) leaves the colorpicker's
current-color with only :opacity — no :image, :gradient, or :color.
update-colorpicker-color's WatchEvent then constructed
`(add-recent-color partial)`, which runs the value through
`clr/check-color` and threw "expected valid color". The user saw an
Internal Assertion Error toast and lost the in-flight upload.
The existing `ignore-color?` guard reads `:type` from the *output* of
`get-color-from-colorpicker-state` — but that helper strips :type from
its result, so the guard never actually fires. Add a schema-based gate
(same validator add-recent-color itself uses) right before `rx/of`, so
a partial selection is silently dropped instead of crashing the
workspace. Behaviour for fully-valid colors is unchanged.
Tests cover three cases: (1) a partial image-tab state with only
:opacity returns nil from watch (was: throws); (2) the same partial
shape on the color tab also returns nil — pinning down that the prior
:type guard wouldn't have caught it; (3) a fully-populated plain color
still produces a watch observable so the guard isn't over-eager.
Closes#8443
Co-authored-by: Andrey Antukh <niwi@niwi.nz>
