Updates `tauri-plugin-shell` from vulnerable version to `v2.2.1` to
address `CVE-2025-31477` in `open` around scope validation.
Affects both `hoppscotch-agent` and `hoppscotch-desktop`.
Closes FE-1022
This resolves window accumulation during instance switching by
implementing proper window lifecycle management using Tauri's
WebviewWindow APIs.
Co-authored-by: jamesgeorge007 <25279263+jamesgeorge007@users.noreply.github.com>
The rebases and updates desktop's `@hoppscotch/plugin-appload`
dependency from branch-based ref to specific commit hash to resolve
Docker build failures.
Branch-based GitHub dependencies require `git` in the build environment.
Our Dockerfile stages didn't install `git`, which caused `pnpm install`
to fail with `spawn git ENOENT`. Using a commit hash allows `pnpm` to
fetch the tarball directly without requiring `git`.
This implements backend path management, backup system, cross-platform utilities, and refactors the `appload` plugin arch to support portable mode deployment.
The changes are mainly establishing foundational infra maintaining current frontend behavior until phase-3+ integration.
- This standardises package versions between desktop, agent, appload, relay
all the native components to resolve version inconsistencies and prepare
for unified bumps in the future.
- Account for recent minor dependency bumps as a follow-up to #5329
Co-authored-by: jamesgeorge007 <25279263+jamesgeorge007@users.noreply.github.com>
This fixes file uploads incorrectly showing MIME type as "Other" instead
of their actual content types by expanding the `MediaType` enum relay
to include common audio, video, and image formats.
Basically `MediaType` enum is used for both `ContentType` which would
map to `ContentType` from `hoppscotch-data` (e.g. `multipart/form-data`)
but also to `FormValue` in `interop`
```rust
pub enum FormValue {
...
File {
filename: String,
content_type: MediaType,
data: Bytes,
},
}
```
although the later should be much more pervasive.
This is a follow up on #5244
Closes FE-887
Closes#3810Closes#5223Closes#5233
The issue occurred because the `relay`'s `MediaType` couldn't deserialize
beyond the basic types (text, JSON, XML, etc.), lacked support for
other media file types. The TypeScript layer correctly detected MIME
types (e.g., "audio/x-m4a"), but the deserialization process fell back
to `MediaType::Other`. Main reason for servers performing strict MIME
validation to reject uploads.
This attempts to resolve app startup failures on Linux systems
where IPv6 is disabled at the kernel level by replacing the dual-stack
port selection logic with network interface discovery.
Closes FE-912
Closes#4962
This adds test coverage for the tab navigation methods added in FE-907
the native tab keyboard shortcuts implementation.
Closes FE-909
The recently implemented desktop tab keyboard shortcuts added new tab
navigation methods to the `TabService` class (`goToNextTab()`,
`goToPreviousTab()`, `goToFirstTab()`, `goToLastTab()`,
`goToTabByIndex()`, and `reopenClosedTab()`). These methods lacked
corresponding test coverage.
This adds documentation for the Hoppscotch Agent package covering
installation, configuration, and usage.
Closes FE-942
Closes#5284
The agent package lacked user-facing documentation beyond the minimal
Tauri template content. Users needed guidance for installation,
registration, certificate management, proxy configuration, and
troubleshooting.
Replaces CodeMirror with Monaco for scripting editors under the experimental scripting sandbox.
The legacy CodeMirror-based editors are preserved for backwards compatibility and will
continue to power the legacy scripting sandbox.
This introduces improved type support, IntelliSense, and JSDoc hinting via Monaco, with
the backing for pre-request and post-request scripts in tabbed views. Type definitions are
isolated per editor to avoid variable leakage.
This implements consistent cross-platform quit functionality that
triggers graceful application shutdown through native native commands.
Closes FE-919
The Cmd + Q quit shortcut was previously broken across platforms with
inconsistent behavior, working on Windows 11 but failing on macOS,
AppImage Linux, and Windows 10. The implementation was mixed and
unreliable.
This updates `vue-tsc` to version `2.2.0` and removes caret prefix from
TypeScript to resolve build compatibility issues that were preventing
builds in `agent`'s CI/CD pipeline.
The build process was failing with "Search string not found" errors when
vue-tsc attempted to patch TypeScript's internal structure.
Initially thought to be related to FE-925, FE-924.
Closes FE-926
The previous config used `TypeScript` at `^5.8.3` with `vue-tsc` at
`^2.1.6`. The `vue-tsc` package contains hardcoded regex patterns for
patching TypeScript's internals, and these patterns in version 2.1.6
don't match the structure in TypeScript 5.8.3.
This adds tab navigation shortcuts to the shortcuts help dialog for
desktop users and conditionally shows them only in desktop mode.
The shortcuts help now includes a "Tabs" section with all available tab
management shortcuts, but only displays them when running in desktop
kernel mode to avoid confusing web users with non-functional shortcuts.
Closes FE-917
The desktop app already had functional tab navigation shortcuts, but
they weren't documented in the app's shortcuts help dialog (accessible
via `?` or `Cmd/Ctrl+/`). This made the shortcuts less discoverable for
users who wanted to learn about available keyboard controls.
The unstable flag was causing arrow keys to
display ANSI escape sequences as literal text
instead of performing cursor navigation.
For example the arrow keys in URL input fields
display escape sequences (`^[[C, ^[[D, ^[[A, ^[[B`)
as literal text.
Closes HFE-880
Closes#5102
The unstable feature flag was originally added to
support experimental features that were required
for functionality that is no longer needed
in the current implementation.
See:
- [Tauri Issue #9257] - Keyboard shortcuts broken with unstable flag
- [Tauri Issue #10194] - Arrow keys printing invalid characters
- [Wry Issue #1177] - Related macOS input handling issues
- CLI Collection runner enhancements:
- Support mixed versions - child collections based on different versions compared to the parent collection.
- Better support for incoming data via IDs conforming to older formats.
- Bump `verzod` across packages.
- Relevant updates to test suite.
- Bump `zod` under `selfhost-desktop`.
* chore: prettier formatting applied
* chore: added some lint fixed
* fix: few lint errors
* chore: prisma and pubsub are now global module
* chore: add encapsulation consistency in service files
* chore: made a cast function private
* chore: cast function made private
* refactor: module imports
* refactor: posthog spelling
fix: handle missing Content-Type when importing curl POST
When importing a curl POST request with a body and no explicit
Content-Type, default to `application/x-www-form-urlencoded`
to match curl's behavior.
Reference: https://everything.curl.dev/http/post/content-type.html
This PR adds a file-based logging system with size-based rotation to the desktop application. It essentially redirects existing diagnostic to size-based rotating files for troubleshooting environment-specific issues.
Closes HFE-801
The desktop application currently lacks a persistent logging mechanism in production environments. Logs are only available through the development mode console.
This PR will help diagnose issues reported in #4859, #4950, #5003, discussions #4984 and #4986.
Mainly aiming to understand errors in specific environments that can't be reproduced in our testing setups.
This implementation uses the tracing ecosystem (`tracing`, `tracing_subscriber`, `tracing_appender`) along with `file_rotate` to create log files in the platform's log directory. The logs are automatically rotated when they reach `10MB`, with a maximum of `5` files retained.
Thinking 10 * 5 MB is reasonable disk usage while maintaining sufficient history.
The system currently writes to both the console (with ANSI colors where supported) and to files (without ANSI formatting for readability). Log levels are currently controlled via the `RUST_LOG` environment variable, defaulting to "debug" when not specified.
| OS | Log File Path |
|---------|------------------------------------------------------|
| Windows | `C:\Users\<username>\AppData\Local\io.hoppscotch.desktop\logs\io.hoppscotch.desktop.log` |
| macOS | `~/Library/Logs/io.hoppscotch.desktop/io.hoppscotch.desktop.log` |
| Linux | `~/.local/share/io.hoppscotch.desktop/logs/io.hoppscotch.desktop.log` |
This fix replace `sys-info v0.9.1` with
the more actively maintained `sysinfo 0.34.2`
which does return size of the disk in bytes.
Closes#5017, HFE-831
Rebased on #5010, consider merging that first.
Issues:
Appload fails to load with a "Storage full" error despite
having sufficient disk space.
This was caused by a unit mismatch in the `sys-info` crate
which returns disk space in kilobytes instead of bytes.
- sys_info::disk_info() returns values in KB, see:
60ecf1470a/c/linux.c (L119)
- The `StorageFull` error was triggered when comparing
raw bytes against a KB value, causing false positive
Changes:
- Rewrite the `ensure_space` function to find the correct disk of the config dir
- Add a new `StorageError::DiskNotFound` for cases where the disk cannot
be resolved
fix: add win version checks for DWM attr api
This adds version checking before using Windows 11-specific DWM APIs.
Closes HFE-821
The desktop app crashes on startup on older Windows versions (pre-Windows 11)
due to unsupported DWM API calls for dark mode and caption styling.
According to docs at https://learn.microsoft.com/en-us/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute,
both `DWMWA_USE_IMMERSIVE_DARK_MODE` and `DWMWA_CAPTION_COLOR` attributes
are only supported starting with Windows 11 Build 22000.
> DWMWA_USE_IMMERSIVE_DARK_MODE: [...] This value is supported starting
> with Windows 11 Build 22000"
and
> DWMWA_CAPTION_COLOR: [...] This value is supported starting
> with Windows 11 Build 22000.
See https://github.com/hoppscotch/hoppscotch/discussions/4984 for more details,
for reports of app crashing immediately on startup with these errors:
```
Failed to set dark mode: Error { code: HRESULT(0x80070057), message: "The parameter is incorrect." }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[0417/150158.530:ERROR:window_impl.cc(122)] Failed to unregister class Chrome_WidgetWin_0. Error = 1412
```
The tests were all over the place, both attributes (sometimes!) seems to be present
on Windows 10 1809 and even earlier, only if it was installed with network access,
so perhaps this is due to Windows updates? Other times, they weren't, especially on VMs.
The issue is reproducible on Windows Server 2019 Datacenter (v10.0.17763),
which is equivalent to Windows 10 version 1809.
This version is too old to support DWMWA_USE_IMMERSIVE_DARK_MODE,
which is only **officially supported** starting with Windows 11 Build 22000
according to Microsoft's documentation.
So at the moment, relying on official docs seems to be the right call,
and themes are definitely something app shouldn't crash for regardless.
These changes add explicit `Content-Type` headers to direct (via `native` interceptor)
authentication requests after changes made in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) that modified how `Content-Type`
headers are handled in the `relay` plugin.
In [issue #4905](https://github.com/hoppscotch/hoppscotch/issues/4905), that was about Hoppscotch Agent and Native interceptor inconsistently
handling `Content-Type` headers. The issue had two main manifestations,
duplicate headers - when overriding the `Content-Type` header in the UI or using OAuth2 authentication, the agent
would send multiple `Content-Type` headers to the web server. This caused undefined behavior
and often 400 errors for backends that don't accept duplicate headers.
And inconsistent overrides - even when the content type was explicitly set (for example to
`application/json;v=2`), the agent/native would inconsistently apply this override. Server
logs revealed that roughly 50% of requests would use the correct override value, while the
others would revert to the default `application/json`.
The two-part solution implemented first in [PR #4911](https://github.com/hoppscotch/hoppscotch/pull/4911) addressed the duplicate headers issue
by implementing header normalization before final relay. This prevented duplicate headers
with different casing from being sent and [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) then resolved the inconsistent override
behavior by removing the automatic `Content-Type` header insertion in the `ContentHandler`
component. As explained in the PR description, this was a temporary workaround until we
implement a HTTP/2-compliant solution with proper normalization.
While the fixes in PR #4911 and #4931 correctly resolved the header inconsistency issues
for general API requests, they introduced a new problem: **requests that previously relied
on the automatic `Content-Type` insertion now have no `Content-Type` header at all**.
This mainly affects direct calls around authentication flows in the desktop module, which
were using the `content.json()` functionality without explicitly setting `Content-Type`
headers, relying on the automatic insertion that has now been removed.
These changes add the now-required explicit `Content-Type` headers to three
authentication-related API calls in the desktop platform module:
- **The initial user details GraphQL query**:
```javascript
headers: {
Authorization: `Bearer ${accessToken}`,
"Content-Type": "application/json",
},
```
- **The magic link email submission endpoint**:
```javascript
headers: {
"Content-Type": "application/json",
},
```
- **The token verification endpoint**:
```javascript
headers: {
"Content-Type": "application/json",
},
```
This will make sure that authentication flows continue to work properly with the native
interceptor after the header handling changes.
As noted in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931), this is considered a **temporary solution**. The plan is to revisit the
content-type handling when we implement a more comprehensive HTTP/2-compliant header
normalization system in the kernel layer.
While HTTP/1.1 headers are case-insensitive
per [RFC 7230](https://tools.ietf.org/html/rfc7230), inconsistent handling across server implementations can treat differently-cased
variations as distinct headers. HTTP/2 ([RFC 7540](https://tools.ietf.org/html/rfc7540)) mandates converting all header field
names to lowercase, which would prevent these issues altogether. In such cases, relying
fully on `MediaType` interface from the kernel will help handling these edge-cases.
The current implementation causes duplicate `Content-Type` headers when users
override headers in the UI or use OAuth2 authentication with the agent.
Web servers receive multiple `Content-Type` headers which causes
undefined behavior and 400 errors for backends that don't accept duplicate headers.
This also fixes inconsistent behavior when overriding the `Content-Type` header
with custom values (e.g., `application/json;v=2`).
While HTTP/1.1 headers are case-insensitive per RFC 7230, inconsistent handling
across server implementations can treat differently-cased variations (e.g.,
"Content-Type" vs "content-type") as distinct headers. HTTP/2 (RFC 7540) mandates
converting all header field names to lowercase, which would prevent this issue.
This patch removes the automatic content-type header insertion, allowing user-defined
headers to take precedence without duplication. The is a temporary
workaround until we implement a HTTP/2-compliant solution with proper normalization.
This was implemented initially to support moving lower level handling
towards the kernel, although since the larger refactor has been slightly
deferred in favor of stability, this change is suitable for current
state.
This will be revisited when we implement HTTP/2 compliant header handling in the
kernel layer as part of our upcoming kernel efforts.
Use the following request to test this out on Desktop app and Agent and
override `Content-Type` header to `application/json;=v2`:
```
curl --request POST \
--url 'https://echo.qubit.codes/?qp=1' \
--header 'Content-Type: application/json;v=2' \
--data '{ "test-key": "test-value" }'
```
This change sorts environment variables alphabetically before they're
processed with import-meta-env that injects them into the index.html.
This makes sure consistent hashes across pod restarts when there aren't
any functional changes made to the `.env` file.
The issue was affecting desktop app reconnections after k8s pod restarts.
The cause was non-deterministic env var ordering (a sideeffect of `Map`)
during the import-meta-env injection process. Even when the env vars
themselves didn't change, their order in the injected JSON could change,
ultimately resulting in different file hashes.
This fix ensures that regardless of the order in which env vars are
provided by the runtime, they will be sorted alphabetically before being
written to the build.env file.
This is observed particularly in the cloud offering. The proposed changes ensure the relevant login state is confirmed before the network call, maintaining backwards compatibility with SH.
