- Introduced a new context menu item for exporting OpenAPI specs.
- Implemented exportOpenApiSpec method in ExportFlow to handle the export process.
- Created a new ApiSpecExportFormat enum for specifying export formats.
- Enhanced ExportPage to manage the export dialog for OpenAPI specs.
- Added tests to verify exporting OpenAPI specs as YAML and JSON, including handling of empty specs.
Both were speculative fixes for the "Create project" dialog hang,
based on a lock-contention/slow-network hypothesis later disproven by
CI timing diagnostics (see 36ea5dce6) — the actual bug was
ProjectModal's close effect, now fixed separately.
Keeping them isn't just unnecessary, it's a regression risk: the 15s
lock-acquire timeout would fire against runKonnectOrgMigration
(src/konnect/migrate-konnect-organization.ts), which holds projectLock
for a synchronous loop over every migratable project and can
legitimately run past 15s for accounts with many projects — turning
a previously-fine "wait it out" into a spurious "Timed out waiting for
another project operation to finish" error on project creation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CI timing diagnostics (added in 66a777f86) showed project creation
completing in ~13ms with zero lock contention and zero network delay,
disproving the two prior hypotheses (lock contention, slow
team-projects fetch). The real bug: ProjectModal's close effect
watched `useNavigation().state` flipping away from 'idle' to detect
the post-create redirect, but a redirect that resolves fast enough can
settle back to 'idle' within the same render/commit, so the effect
never observes the transient state and the modal never closes — with
no error, since the create itself succeeded. Fixed by comparing the
pathname captured when the modal opened against the current location
instead, which can't be missed regardless of timing.
Removes the now-unnecessary temporary timing diagnostics. Keeps the
lock-acquire timeout and bounded team-projects fetch timeout as
reasonable defensive improvements, even though neither was the actual
cause of the CI hangs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two prior fixes (lock acquire timeout, bounded team-projects fetch
timeout) targeted the wrong bottleneck — the mock API's team-projects
endpoint responds instantly with no artificial delay, so the CI hang is
coming from somewhere else. Add console.log timing around lock
wait/hold time, NeDB project creation, and the team-projects
fetch/sync so the next CI failure's console-log attachment shows
exactly which step is slow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Background: in the environment variables table view and the generic key-value editor, a space typed within 1s of the previous printable character is swallowed (typing "My key" produces "Mykey"); users had to insert spaces via arrow keys afterwards. Raw JSON editing is unaffected.
The react-aria ListBox typeahead (useTypeSelect) intercepts space keydowns in the capture phase while its search buffer is non-empty. Disable typeahead via disallowTypeAhead on the ListBoxes that embed inline editors (environment key-value editor and the generic key-value editor), remove the now-obsolete space<->NBSP keydown workaround, and add a module augmentation for the prop that is missing from ListBoxProps typings in all published react-aria-components versions.
Add smoke tests typing at human speed (120ms per keystroke) in the environment table, headers, and query params views; zero-delay bursts do not reproduce the bug.
## Background
Toast add/remove animations run through the View Transition API. While such a transition is active, Chromium retargets hit-testing for the whole viewport to `<html>` - including the moment a newer transition skips the running one - so a click can arrive with `document.documentElement` as its target. react-aria's `useInteractOutside` reads such an event as a click outside an open modal and closes it.
Reproduction: open Settings → General → Software Updates and click **Check** repeatedly. Every click fires toasts, every toast mutation starts a view transition, and a click landing in one of those windows closed the Settings modal itself.
## Changes
- `packages/insomnia/src/ui/css/styles.css`: disable pointer events on the `::view-transition` overlay and exclude the root element from the transition, so clicks keep reaching real elements while a toast animates. Both rules are required: the overlay rule alone still leaves the captured root's contents unhittable ([spec rationale](https://drafts.csswg.org/css-view-transitions-1/#view-transition-stacking-layer)), and excluding the root alone still leaves the overlay swallowing the clicks. The same pair is documented for this scenario in [Keeping the page interactive while a View Transition is running](https://www.bram.us/2025/01/29/view-transitions-page-interactivity/) and [csswg-drafts#11596](https://github.com/w3c/csswg-drafts/issues/11596).
- `packages/insomnia/src/ui/components/toast-notification.tsx`: drop `pointerdown`/`click` events that were retargeted to `<html>` while a view transition is active. Those clicks cannot be attributed to their real target (hit-testing was suppressed by the browser) and were being misread as clicks outside an open modal. Events that land on real elements are untouched. Registration is guarded with `typeof window !== 'undefined'` because this module is also evaluated in Node (dev server, prerender).
- `packages/insomnia/src/ui/components/toast-notification.tsx`: remove the stale `[view-transition-name:toast]` utility, which the inline per-toast `view-transition-name` has always overridden.
- `packages/insomnia/src/ui/css/styles.css`: remove the `::view-transition-new(toast)` / `::view-transition-old(toast)` slide rules and their keyframes. They selected a group named `toast`, which never existed because toasts need unique names (a duplicate `view-transition-name` aborts the whole transition), so they never applied.
- `packages/insomnia/src/ui/components/check-for-updates-button.tsx`: the button was fully disabled in development mode, which made this bug impossible to reproduce manually. It now shows a toast instead ("Updates are disabled in development mode"). Production behaviour is unchanged.
## Notes
- Measured with real (CDP/`sendInputEvent`) input against the real components in Electron 43.2.0 / Chromium 150.0.7871.129: without the change a click during a toast animation hits `<html>` and closes the modal; with it the button keeps receiving clicks (25/17/12 clicks handled for 60/90/130ms click intervals) and the modal stays open.
- No regressions measured: clicks while no transition runs (20/20 handled), mask click dismissal, Escape dismissal, popover outside-click dismissal (also while a transition runs), and clicking a toast.
- Residual: hit-testing still returns `<html>` for the fraction of a click that lands inside a transition window (~10% of samples under rage clicking) - that is compositor behaviour and cannot be opted out. Such clicks are now dropped instead of dismissing the modal, which means that one click does nothing.
- `:root { view-transition-name: none }` applies to every view transition in the app; the rule is commented in place so it is revisited if transitions other than toasts are introduced.
Related: https://github.com/Kong/insomnia/pull/10553
Bob Qiu