penpot/penpot

Is your feature request related to a problem? Please describe. When I am swapping a copy for another component and I am not sure which connected library it lives in, I want to look for the same name in each library without typing it again, so I can find the right component quickly and get back to the design.* Today, the search in the Swap component menu is cleared every time the library is changed in the library selector. A designer who types "button primary", finds nothing in the file library and switches to a connected shared library lands on the full component list of that library, with an empty search field. To check three libraries, they type the same name three times. This happens most in files with several shared libraries connected (a design system split into core, icons and product-specific libraries, for example). The search is a filter on what the designer is looking for, not on the library, so losing it when the library changes breaks the flow at the moment the designer is

Steps To Reproduce Open any plugin built with @penpot/plugin-styles, for instance the bundled MCP one at /plugins/mcp/. Open the network tab and look for a request to fonts.bunny.net. On a deployment with the Content Security Policy enabled, open the browser console instead: the violations are reported there. Reading the source is enough too: plugins/libs/plugins-styles/src/lib/core/fonts.css starts with a remote @import, and that file is pulled in by styles.css, the entry point of the package. Expected behavior A plugin renders with its intended typography without the browser reaching out to any domain other than the Penpot installation's own, so that it also works on an air-gapped deployment and 'self' is enough to cover it in the Content Security Policy. Actual behavior plugins/libs/plugins-styles/src/lib/core/fonts.css starts with a remote import: @import url('https://fonts.bunny.net/css?family=work-sans:400,500&display=swap'); Since styles.css pulls that file in and styles.css i

Is your feature request related to a problem? Please describe. When creating new pages in the layers sidebar, you can reposition the new layer in the list by dragging. However, you're not able to hold the layer and scroll up. Instead, one has to rely on the auto-scrolling that happens when holding the layer toward the top of the list. This is not ideal, as it requires motion dexterity and precision. Describe the solution you'd like. Allow for layer repositioning to combine mouse scrolling Describe alternatives you've considered. No response Additional context No response

Steps To Reproduce To (hopefully?) reproduce the issue: On the server, run ps faux | grep chrome-headless | grep defunct | grep -v "grep", no result On the penpot frontend, go to project, create a new file Add a new Board Go to Design, click on the "+" to add a new Export Click "Export 1 Element" Wait a few seconds (for some reason ? It's longer than just waiting for the exported file) On the server, run ps faux | grep chrome-headless | grep defunct | grep -v "grep", 2 new zombie processes exist. Expected behavior The chrome-headless (forked?) processes get joined (waited?) by the parent process when they're done, leaving no zombie process behind. Actual behavior We're currently self-hosting Penpot on an Ubuntu machine via Docker. Every time someone exports an element using the UI, 2 new zombie processes are created on the server, children of the penpot-exporter container. I haven't seen anything on the patch notes from recent releases that would tell me this has been fixed in more

Is your feature request related to a problem? Please describe. In the workspace, once the search UI is open (either Search layers or Search on canvas), there is no keyboard way to dismiss it — closing requires reaching for the close (X) control with the mouse. Pressing Escape is the standard convention in most tools and operating systems for dismissing panels, dialogs, and overlays. Not supporting it here breaks a deeply ingrained habit and interrupts keyboard-first workflows. This is a small UX enhancement complementary to the toggle behaviour described in #9528, and sits on top of the search work landing in the 2.16 milestone (related context: PR #8899). Panels in scope The following panels have been identified as missing Escape-to-close support: Search (Search layers / Search on canvas) — related to #9528 and PR #8899 History Shortcuts Other panels in the workspace should be audited and brought into alignment with this behaviour where applicable. Describe the solution you'd li