Swarm Fix: [BUG] [alpha] TerminalLinkProvider fallback uses window.open when shell_open fails#38290
Conversation
…open when shell_open fails Signed-off-by: hinzwilliam52-ship-it <hinzwilliam52@gmail.com>
📝 WalkthroughWalkthroughA new proposal document Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@FIX_PROPOSAL.md`:
- Around line 1-6: The comment is asking to clarify whether the fix belongs in
frontend or backend: update TerminalLinkProvider to use Tauri's JS API rather
than falling back to window.open; replace the fallback in TerminalLinkProvider
with a call to `@tauri-apps/api/shell.open` (or use invoke to call a dedicated
backend command that uses tauri::api::shell::open or tauri::Window::open) so the
link opens in the system browser; locate the fallback code in
TerminalLinkProvider (where window.open is used) and change it to call the JS
shell.open or an invoke('open_external', { url }) bridge to Rust (if you prefer
backend), ensuring the chosen layer (frontend TerminalLinkProvider vs Rust
tauri::Window) is documented in the PR description.
- Around line 28-39: The snippet uses the JavaScript invoke("shell_open", ...)
and an unused Window import and calls tauri::shell::open(...) with the wrong
signature; fix by removing the incorrect invoke usage and the unused Window
import, then implement the correct Tauri shell API for your targeted version:
for Tauri v1 use tauri::api::shell::open(path, Option<Program>, &ShellScope)
providing a valid ShellScope, or for Tauri v2 initialize and call the Shell
plugin API (or switch to tauri-plugin-opener and call open_path()/openUrl());
update the call site replacing tauri::shell::open with the proper module path
and required parameters (ShellScope or plugin instance) so the code compiles.
- Around line 7-22: The snippet misuses frontend invoke and window APIs: replace
the invalid invoke("shell_open", ...) call with the proper Rust API (e.g.,
tauri::api::shell::open(&app.shell_scope, "https://example.com", None) for Tauri
v1 or use the recommended tauri-plugin-opener/opener.open_url(...) approach for
v2), remove the incorrect WindowBuilder::new(tauri::generate_handler![]) /
.build(tauri::generate_context!()) usage (do not call generate_handler! or
generate_context! when building windows) and drop the unused Window import; also
ensure the required "shell-open" feature and tauri.conf.json permissions (or the
appropriate plugin and Cargo features) are enabled so the call opens the URL in
the system external browser rather than creating an embedded window.
- Around line 1-41: The proposal mixes frontend and backend Tauri APIs; update
TerminalLinkProvider to use the correct API for its runtime: if
TerminalLinkProvider is frontend/TypeScript, replace the incorrect Rust-like
snippets with a try { await invoke('shell_open', { url: link }); } catch { await
open(link); } flow using invoke and open from `@tauri-apps/api` (reference:
invoke, open, TerminalLinkProvider); if TerminalLinkProvider is Rust/backend,
remove any frontend invoke/open usage and call tauri::api::shell::open(&url,
None).ok() (reference: tauri::api::shell::open) and remove the WindowBuilder
approach since it’s not appropriate for opening external URLs. Ensure the code
paths and imports match the chosen context and remove mixed-language examples
(WindowBuilder, invoke) so only the correct API remains.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| To address the issue of `TerminalLinkProvider` falling back to `window.open` when `shell_open` fails, we need to implement a more reliable fallback mechanism that works within the Tauri framework. | ||
|
|
||
| Given the constraints and the goal of opening a URL externally in a way that's compatible with Tauri, we can utilize the `tauri::Window` API to launch the URL. This approach ensures that the URL is opened in the default system browser, providing a consistent user experience across different platforms. | ||
|
|
||
| Here's a concise code snippet that demonstrates how to achieve this: | ||
|
|
There was a problem hiding this comment.
Clarify whether this is a frontend or backend fix.
The proposal mentions TerminalLinkProvider falling back to window.open (a browser/JavaScript API), but then proposes Rust code solutions. If TerminalLinkProvider is a frontend TypeScript/JavaScript component, the fix should likely be implemented in the frontend code using Tauri's JavaScript API (invoke, @tauri-apps/api/shell), not in Rust backend code. Please clarify the context and intended implementation layer.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@FIX_PROPOSAL.md` around lines 1 - 6, The comment is asking to clarify whether
the fix belongs in frontend or backend: update TerminalLinkProvider to use
Tauri's JS API rather than falling back to window.open; replace the fallback in
TerminalLinkProvider with a call to `@tauri-apps/api/shell.open` (or use invoke to
call a dedicated backend command that uses tauri::api::shell::open or
tauri::Window::open) so the link opens in the system browser; locate the
fallback code in TerminalLinkProvider (where window.open is used) and change it
to call the JS shell.open or an invoke('open_external', { url }) bridge to Rust
(if you prefer backend), ensuring the chosen layer (frontend
TerminalLinkProvider vs Rust tauri::Window) is documented in the PR description.
| To address the issue of `TerminalLinkProvider` falling back to `window.open` when `shell_open` fails, we need to implement a more reliable fallback mechanism that works within the Tauri framework. | ||
|
|
||
| Given the constraints and the goal of opening a URL externally in a way that's compatible with Tauri, we can utilize the `tauri::Window` API to launch the URL. This approach ensures that the URL is opened in the default system browser, providing a consistent user experience across different platforms. | ||
|
|
||
| Here's a concise code snippet that demonstrates how to achieve this: | ||
|
|
||
| ```rust | ||
| use tauri::{Window, WindowBuilder}; | ||
|
|
||
| // Assuming `link` is the URL you want to open | ||
| let link = "https://example.com"; | ||
|
|
||
| // Attempt to open the link using shell_open | ||
| if let Err(_) = invoke("shell_open", link) { | ||
| // Fallback: Open the link using tauri::Window | ||
| WindowBuilder::new(tauri::generate_handler![]) | ||
| .title("External Link") | ||
| .url(link) | ||
| .build(tauri::generate_context!()) | ||
| .expect("Failed to create window"); | ||
| } | ||
| ``` | ||
|
|
||
| However, since creating a new window just to open a link might not be the most efficient or user-friendly approach, we can also consider using the `webview` API provided by Tauri to open the link in the default browser. Unfortunately, Tauri's API does not directly support launching external URLs without creating a new window or using `shell_open`. | ||
|
|
||
| An alternative and more straightforward approach, considering the limitations, is to use the `open` command provided by Tauri, which allows you to open a URL in the system's default browser: | ||
|
|
||
| ```rust | ||
| use tauri::Window; | ||
|
|
||
| // Assuming `link` is the URL you want to open | ||
| let link = "https://example.com"; | ||
|
|
||
| // Attempt to open the link using shell_open | ||
| if let Err(_) = invoke("shell_open", link) { | ||
| // Fallback: Open the link using the open command | ||
| tauri::shell::open(link).expect("Failed to open link"); | ||
| } | ||
| ``` | ||
|
|
||
| This approach is more in line with the expected behavior and provides a reliable fallback when `shell_open` fails, ensuring that the URL is opened in the default system browser. No newline at end of file |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
fd -type f -name "FIX_PROPOSAL.md"Repository: PlatformNetwork/bounty-challenge
Length of output: 246
🏁 Script executed:
git ls-files | head -20Repository: PlatformNetwork/bounty-challenge
Length of output: 564
🏁 Script executed:
find . -name "Cargo.toml" -o -name "package.json" | head -10Repository: PlatformNetwork/bounty-challenge
Length of output: 117
🏁 Script executed:
cat -n FIX_PROPOSAL.mdRepository: PlatformNetwork/bounty-challenge
Length of output: 2444
🏁 Script executed:
cat -n Cargo.tomlRepository: PlatformNetwork/bounty-challenge
Length of output: 1121
🏁 Script executed:
cat -n Cargo.toml | head -50Repository: PlatformNetwork/bounty-challenge
Length of output: 1121
🏁 Script executed:
grep -r "TerminalLinkProvider" --include="*.rs" --include="*.ts" --include="*.tsx"Repository: PlatformNetwork/bounty-challenge
Length of output: 58
🏁 Script executed:
grep -r "shell_open\|tauri::" --include="*.rs" | head -20Repository: PlatformNetwork/bounty-challenge
Length of output: 58
🏁 Script executed:
fd -name "*.rs" | head -20Repository: PlatformNetwork/bounty-challenge
Length of output: 306
🏁 Script executed:
fd -name "*.ts" -o -name "*.tsx" | head -20Repository: PlatformNetwork/bounty-challenge
Length of output: 306
🏁 Script executed:
cat -n README.md 2>/dev/null || echo "No README.md found"Repository: PlatformNetwork/bounty-challenge
Length of output: 11196
🏁 Script executed:
git log --oneline --all | grep -i "terminal\|link\|window" | head -10Repository: PlatformNetwork/bounty-challenge
Length of output: 581
🏁 Script executed:
git log --all --oneline --grep="TerminalLinkProvider\|terminallinkprovider"Repository: PlatformNetwork/bounty-challenge
Length of output: 179
🏁 Script executed:
git show 6d6625fRepository: PlatformNetwork/bounty-challenge
Length of output: 50391
🏁 Script executed:
find . -name "*.md" -type f | xargs grep -l "TerminalLinkProvider\|shell_open" 2>/dev/nullRepository: PlatformNetwork/bounty-challenge
Length of output: 93
Proposal contains API confusion — requires revision.
The proposal mixes frontend and backend Tauri APIs. The code snippets show:
- Line 14:
invoke("shell_open", link)— this is a frontend function, not valid in Rust - Lines 16-20:
WindowBuilder::new()with invalid arguments; this pattern doesn't create external URL windows in Tauri - Line 37:
tauri::shell::open()is the correct Rust API but contradicts earlier snippets
Correct approaches:
For TypeScript/Frontend (Cortex IDE likely uses this):
import { open } from '@tauri-apps/api/shell';
try {
await invoke('shell_open', { url: link });
} catch {
await open(link);
}For Rust backend:
use tauri::api::shell;
shell::open(&url, None).ok(); // Returns Result, no unwrap neededClarify which context applies to TerminalLinkProvider and revise accordingly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@FIX_PROPOSAL.md` around lines 1 - 41, The proposal mixes frontend and backend
Tauri APIs; update TerminalLinkProvider to use the correct API for its runtime:
if TerminalLinkProvider is frontend/TypeScript, replace the incorrect Rust-like
snippets with a try { await invoke('shell_open', { url: link }); } catch { await
open(link); } flow using invoke and open from `@tauri-apps/api` (reference:
invoke, open, TerminalLinkProvider); if TerminalLinkProvider is Rust/backend,
remove any frontend invoke/open usage and call tauri::api::shell::open(&url,
None).ok() (reference: tauri::api::shell::open) and remove the WindowBuilder
approach since it’s not appropriate for opening external URLs. Ensure the code
paths and imports match the chosen context and remove mixed-language examples
(WindowBuilder, invoke) so only the correct API remains.
| ```rust | ||
| use tauri::{Window, WindowBuilder}; | ||
|
|
||
| // Assuming `link` is the URL you want to open | ||
| let link = "https://example.com"; | ||
|
|
||
| // Attempt to open the link using shell_open | ||
| if let Err(_) = invoke("shell_open", link) { | ||
| // Fallback: Open the link using tauri::Window | ||
| WindowBuilder::new(tauri::generate_handler![]) | ||
| .title("External Link") | ||
| .url(link) | ||
| .build(tauri::generate_context!()) | ||
| .expect("Failed to create window"); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check Tauri version and API documentation for shell::open
# Find Cargo.toml to determine Tauri version
fd -t f "Cargo.toml" -x grep -H "tauri"
# Search for existing shell::open usage patterns in the codebase
rg -n "shell::open|api::shell" --type rust -C 3Repository: PlatformNetwork/bounty-challenge
Length of output: 58
🌐 Web query:
What is the correct Rust API to open a URL in the default system browser in Tauri v1.x and v2.x? Specifically, how to use shell::open from Rust backend code?
💡 Result:
Tauri v1.x (core API): use tauri::api::shell; shell::open(&app.shell_scope, "https://example.com", None).unwrap; Requires "shell-open-api" feature enabled on tauri crate and "shell": {"open": true} in tauri.conf.json allowlist. Tauri v2.x (plugins): For shell.open (deprecated since 2.1.0, use opener instead): Add tauri-plugin-shell to Cargo.toml, .plugin(tauri_plugin_shell::init), use app.shell.open("https://example.com", None). Requires ShellExt trait and shell:allow-open permission in capabilities. Recommended: tauri-plugin-opener Add tauri-plugin-opener = "2", .plugin(tauri_plugin_opener::init), in setup: let opener = app.opener; opener.open_url("https://example.com", None). Requires opener:allow-open-url permission. Note: shell::open refers to the old v1 core API; v2 uses plugins with similar method on app extension.
Citations:
- 1: https://docs.rs/tauri/1.0.3/tauri/api/shell/index.html
- 2: https://v2.tauri.app/plugin/opener/
- 3: https://v2.tauri.app/plugin/shell
- 4: https://crates.io/crates/tauri-plugin-opener/2.2.2
- 5: https://docs.rs/tauri-plugin-shell/latest/tauri_plugin_shell/struct.Shell.html
- 6: https://docs.rs/tauri-plugin-shell/latest/tauri_plugin_shell/trait.ShellExt.html
Multiple critical API errors in the first code snippet.
This code snippet contains several fundamental issues with Tauri API usage:
-
invoke("shell_open", link)is invalid in Rust:invokeis a JavaScript/TypeScript function from@tauri-apps/api/tauri, not a Rust function. In Rust backend code, use:- Tauri v1.x:
tauri::api::shell::open(&app.shell_scope, "https://example.com", None)(requires"shell-open-api"feature in Cargo.toml and"shell": {"open": true}in tauri.conf.json) - Tauri v2.x:
tauri-plugin-shellortauri-plugin-opener(recommended). For example, with opener:app.opener.open_url("https://example.com", None)(requires appropriate feature plugins and permissions)
- Tauri v1.x:
-
WindowBuilder::new(tauri::generate_handler![])is incorrect:WindowBuilder::new()does not accept a handler array. Thegenerate_handler!macro is used when creating the Tauri app to register commands, not when building windows. -
.build(tauri::generate_context!())is incorrect: Thebuild()method requires a reference toApporAppHandle, not aContext. -
Unused import:
Windowis imported but never used. -
Wrong approach: This would open the URL in a new Tauri window (embedded webview), not in the system's default external browser, defeating the stated purpose.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@FIX_PROPOSAL.md` around lines 7 - 22, The snippet misuses frontend invoke and
window APIs: replace the invalid invoke("shell_open", ...) call with the proper
Rust API (e.g., tauri::api::shell::open(&app.shell_scope, "https://example.com",
None) for Tauri v1 or use the recommended
tauri-plugin-opener/opener.open_url(...) approach for v2), remove the incorrect
WindowBuilder::new(tauri::generate_handler![]) /
.build(tauri::generate_context!()) usage (do not call generate_handler! or
generate_context! when building windows) and drop the unused Window import; also
ensure the required "shell-open" feature and tauri.conf.json permissions (or the
appropriate plugin and Cargo features) are enabled so the call opens the URL in
the system external browser rather than creating an embedded window.
| ```rust | ||
| use tauri::Window; | ||
|
|
||
| // Assuming `link` is the URL you want to open | ||
| let link = "https://example.com"; | ||
|
|
||
| // Attempt to open the link using shell_open | ||
| if let Err(_) = invoke("shell_open", link) { | ||
| // Fallback: Open the link using the open command | ||
| tauri::shell::open(link).expect("Failed to open link"); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
❓ Verification inconclusive
Script executed:
#!/bin/bash
# Find the actual shell::open usage in the codebase to determine correct API
rg -n "use tauri.*shell" --type rust -C 2
rg -n "shell::open" --type rust -C 3Repository: PlatformNetwork/bounty-challenge
Repository: PlatformNetwork/bounty-challenge
Exit code: 1
What is the correct function signature for tauri::shell::open in Tauri v1.x versus v2.x? Include parameter types and return types.
Tauri v1.x (JavaScript): open(path: string, openWith?: string): Promise from '@tauri-apps/api/shell' Tauri v1.x (Rust): tauri::api::shell::open(path: impl Into, with: Optiontauri::api::shell::Program, scope: &ShellScope) -> Result<, Error> Tauri v2.x (JavaScript, deprecated in shell plugin): open(path: string, openWith?: string): Promise from '@tauri-apps/plugin-shell'. Recommended: use '@tauri-apps/plugin-opener' with openPath(path: string, openWith?: string): Promise or openUrl(url: string, openWith?: string): Promise Tauri v2.x (Rust): shell.open(&self, path: impl Into, with: Option<tauri_plugin_shell::open::Program>) -> Result<, Error> on the Shell instance (deprecated since 2.1.0, use tauri-plugin-opener::OpenerExt instead with opener.open_path(path: &str, with: Option<&str>) -> Result<, Error> etc.)
Citations:
- 1: https://tauri.app/v1/api/js/shell/
- 2: https://v1.tauri.app/v1/api/js/shell/
- 3: https://v2.tauri.app/reference/javascript/shell/
- 4: https://docs.rs/tauri/1.0.3/tauri/api/shell/index.html
- 5: https://docs.rs/tauri-plugin-shell/latest/tauri_plugin_shell/open/index.html
- 6: https://docs.rs/tauri-plugin-shell/latest/tauri_plugin_shell/struct.Shell.html
- 7: https://crates.io/crates/tauri-plugin-opener/2.2.2
Incorrect invoke() usage and incomplete Tauri shell API implementation.
Issues in this snippet:
-
invoke()error persists:invoke("shell_open", link)is JavaScript API, not valid Rust code. -
Unused import:
Windowis imported but never used. -
Incomplete API implementation: The signature
tauri::shell::open(link)is missing required parameters and context:- Tauri v1.x: API is
tauri::api::shell::open(path, with: Option<Program>, scope: &ShellScope) -> Result<(), Error>. Requires aShellScopeparameter and optional program reference. - Tauri v2.x: Access via the Shell plugin instance (requires initialization), or use the newer recommended
tauri-plugin-opener(v2.1.0+) withopen_path()oropenUrl()methods.
- Tauri v1.x: API is
The code snippet oversimplifies the API call and won't compile as written. Verify which Tauri version this is targeting and use the appropriate module path and parameters.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@FIX_PROPOSAL.md` around lines 28 - 39, The snippet uses the JavaScript
invoke("shell_open", ...) and an unused Window import and calls
tauri::shell::open(...) with the wrong signature; fix by removing the incorrect
invoke usage and the unused Window import, then implement the correct Tauri
shell API for your targeted version: for Tauri v1 use
tauri::api::shell::open(path, Option<Program>, &ShellScope) providing a valid
ShellScope, or for Tauri v2 initialize and call the Shell plugin API (or switch
to tauri-plugin-opener and call open_path()/openUrl()); update the call site
replacing tauri::shell::open with the proper module path and required parameters
(ShellScope or plugin instance) so the code compiles.
1 participant
Description
Brief description of the changes in this PR.
Related Issue
Fixes #(issue number)
Type of Change
Checklist
Testing
Describe the tests you ran to verify your changes.
Screenshots (if applicable)
Add screenshots to help explain your changes.
Summary by CodeRabbit