fix: enable tauri plugin opener

[weareoutman]

Description

Links are not working in latest cinny-desktop. This PR introduces tauri plugin opener to fix it.

Fixes #544 along with cinnyapp/cinny#2799.

Edit: find a solution without touching Cinny web codebase, see comments below #559 (comment).

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[Hifumorenko]

I checked out this PR together with the PR in the Cinny to build and test this fix.

Opening a link results in an ACL exception:

Tested on Windows 11.

[weareoutman]

@Hifumorenko Not a regular Windows user, but I have an Windows 11 VM (x86 64)，when I run npm run tauri dev it initially fails with http 500, because this PR was behind my another fix #556 , after rebase, it works, and opens external links without issue.

Not tried build yet, because this VM runs on a machine performs very poorly.

[weareoutman]

@Hifumorenko reproduced it when run build, just fixed it by adding a remote urls in config.

It seems that using localhost plugin will make localhost as an external URL, and have to be specified as a remote url to make the permissions work when build on Windows.

[Hifumorenko]

@weareoutman the fix is successful - the links open in a web browser now. Thank you! 🙂

[Kruemmelspalter]

has cinnyapp/cinny changed their opinion and now allows tauri-specific patches?
in cinnyapp/cinny#1238 (comment) they said they didn't want any
for my #569, I used a patch file instead which this will require too if upstream doesn't allow tauri-specific patches

[weareoutman]

@Kruemmelspalter In certain cases, essential capabilities on native client can only be achieved by introducing native SDK in web codebase. As long as the team wants to keep their desktop user stay, it's inescapable. E.g., Element Web has to use Electron SDK in their web codebase.

I tried not coupling web and desktop codebase too much, by using dynamic imports conditionally.

Edit: I would not think using patch files to be a better idea, since the web source code is still in active development.

[Kruemmelspalter]

@weareoutman I agree that using dynamic imports in the web codebase would be better, it's just that the cinny web maintainers have said that they don't want to do it like that, so the only other option I see is using the patch files.

I don't think it is a good idea to add Tauri specific changes to web specific codebase. Tauri should suppose to provide the paste data via dom events.

~ cinnyapp/cinny#1238 (comment)

I'm fully with you that it would be better to do upstream.

[weareoutman]

Just come across with a solution without touching Cinny web codebase:

By calling Builder::plugin(tauri_plugin_opener::init()) it already handles native anchor element of <a target='_blank'> by openning it in system browser.

The exception is calling window.open() with JS, such as code in UserChips.tsx.

While It can be handled by using WebviewBuilder::on_new_window which is introduced in tauri v2.8.0, but it's locked in 2.7.0 in cinny-desktop, so I updated deps by calling cargo update.

[kfiven]

Tested on:

• Windows: Working
• Linux: Working
• MacOS: Working

Test build is at https://github.com/cinnyapp/cinny-desktop/actions/runs/24302351398?pr=559

Can we test it on Linux and MacOS?

@weareoutman what OS you tested it on?

[weareoutman]

@kfiven Tested on macOS

[alterNERDtive]

• Linux:

Works.

[Turk1701]

Works on Windows. Thanks!