Opening URLs and applications failing
Creating this as a thread to collect information on why some users experience issues with plugins opening URLs in the browser, which seems to also happen with clicking the "open config directory" button in settings, which makes sense as they use the same mechanism.
84 Replies
@BeeInABlanket ☕🐝: https://discord.com/channels/1143819637897834571/1143819638732505130/1248415607733354708
@Percy_Ikana: https://discord.com/channels/1143819637897834571/1143819638732505130/1260967647013507202
@datarecall: https://discord.com/channels/1143819637897834571/1143819638732505130/1228012332748243005
@thomasvs: https://discord.com/channels/1143819637897834571/1143819638732505130/1270765301415546991
I still have no idea what made it suddenly work
Let me pull the latest code down and give it a try
Thanks!
Can't repro on my main machine under openSUSE Tumbleweed, I'm giving it a go on this Fedora Silverblue laptop I've got but rpm-ostree is being very slow
It took so long and didn't even work due to a missing symbol in the version of webkit2gtk it installed, going to sleep now lol
still not working for me, at least with the appimage version
what distro are you using?
and does the "open config directory" button in settings also not work?
Garuda (Arch-based). and nope
that button also does not work
ok, good to know, does anything happen differently in the AUR version (opendeck-git)?
you will need to install Deno beforehand as it has not yet been added as a dependency to the aur package
hm. normally I just use Octopi to fetch things from AUR, but opendeck isn't showing up in that. searching AUR directly shows
opendeck and opendeck-git, with opendeck-git being the update from early Junewhile the opendeck-git package itself may not have been updated since June, that's just because it's the -git version, which fetches the latest commit automatically
ah
that just means the build logic in the PKGBUILD hasn't been updated since June
(and just to confirm,
xdg-open https://example.com/ and xdg-open ~/ in your normal terminal do work, so it is an OpenDeck issue?)looks like it's aborting on build.
I think you need to upgrade your cargo-tauri version
it should be at least 1.6
and yep, I can launch things fine with the console
ah, the maintainers of that package haven't updated it yet
well, in that case, thanks for your help ig! (unless you want to build it from source without the help of a PKGBUILD but that's up to you, I don't want to intrude on whatever you were doing)
well it's 5am here so I should probably try and sleep, but I can maybe poke around a little bit longer and see if maybe I might luck into this somehow going quick
:pjdHat:
well, all you should have to do is git clone the OpenDeck repo, run
cargo install tauri-cli, and then cargo tauri devfirst command took a bit, second in progress now
it works!
it launches stuff outside itself no problem now!
so probably an appimage issue?
oh, hm. wait, may have spoken too soon
oh, cool!
ok, so, using
cargo tauri dev launched opendeck, and that worked until I closed the konsole (which had the cargo tauri process attached), which then closed the applicationyep
makepkg is still erroring out, but this time it's a bit more verbose and points to an issue with deno
does
cargo tauri build work in your cloned source directory?nope, same error
well, i've just got my computer operable again (was dust cleaning it while going through this with you), so i'll take a look at that error
if you
rm -rf node_modules, rm deno.lock, and then cargo tauri build does it work?no, though
rm deno.lock errors with no such file or directory??
it's literally in the repo lmao
https://github.com/ninjadev64/OpenDeck/blob/main/deno.lock
maybe
git reset --hard main to make it like you've just checked it out fresh"unknown revision or path not in the working tree"... um... hm. OK, lemme back this up a bit and start fresh
:s9welp:
hmm, did you
git clone https://github.com/ninjadev64/OpenDeck.git?close.
git clone https://aur.archlinux.org/opendeck-git.gitah, lmao, that's not the OpenDeck source repo
yeah, that's the one in AUR 😛
going upstream now
wait, how did you
cargo tauri dev then??
maybe makepkg got far enough to download the opendeck sources so you could run it, or somethingGitHub
[bug] Links with target=_blank and shell::open do not work from App...
Describe the bug When running a Tauri app on Linux using an AppImage, target=_blank links do not work, and shell::open does not work either. Reproduction Minimal reproduction repo: https://github.c...
hm. this time around
cargo tauri build is erroring out with failed to bundle project: error running appimage.shGitHub
[bug] failed to bundle project: error running appimage.sh · Issue #...
Describe the bug Build a hello word project, run pnpm tauri build, get a error: Compiling serialize-to-javascript v0.1.1 Compiling serde_repr v0.1.9 Compiling state v0.5.3 Compiling webkit2gtk v0.1...
I'm trying to remember the fix
I think
NO_STRIP=true cargo tauri build
haha, if only we remembered this
https://discord.com/channels/1143819637897834571/1143819638732505130/1245452977066741801ok, that build worked, though the appimage just launches into a blank white screen
haha, there's a thread for this too
https://discord.com/channels/1143819637897834571/1249391951715893339/1249396078357385256
:InaLaugh:
well, with the environment variable from that thread set I can launch the appimage I built, and it seems to be able to open things properly
awesome!
well, not sure why building it from scratch makes everything work, but hopefully some of this gave you some useful info for future appimage releases
and thank you for talking me through this (and building the app in the first place) 😄
no worries!
does the original appimage work now by any chance? just in case building from source installed some dependencies that were needed for it to work
(properly quit the one you built first from your system tray)
sorry, stepped away for a bit. the original appimage presents the same issue as before, failing to open anything outside itself
very strange, but thanks so much for your help!
np! glad to help 😄
@Percy_Ikana does the AppImage from GitHub Releases work for you?
I'm submitting a bug report on Tauri's GitHub and want to document as much as possible; just wondering if I should wait for @Percy_Ikana and @datarecall to be able to test things or if I should go ahead and submit if you guys aren't currently available? (completely fine, by the way!)
oh my apologies Percy, it seems that when we were troubleshooting the issue a while ago (https://discord.com/channels/1143819637897834571/1143819638732505130/1260967647013507202) what fixed it for you was both running from source and installing from the AUR, same sort of thing as Bee
ooh, damn, I can reproduce this now!
it definitely seems to be an issue with the AppImage produced by GitHub Actions (the ones in the releases)
- download AppImage
-
chmod +x opendeck.AppImage
- ./opendeck.AppImage
- click "open config directory"
- it opens whatever this is in the terminal I launched OpenDeck from
it's called w3m apparently
this is left in the terminal after I exit w3m
Appimage failes to open anything still, yhea.
It also reverts to bad spacing
I get no error messages in terminal or logs, though
commands that run purely in the terminal (touch, my amixer playback commands, etc ) all work, it just cant open anything
even when pressing "open config directory"?
aye
alright, but that doesn't matter really at this point
I'm about to submit an issue on the tauri-action repo seeing as it only seems to happen in AppImages produced by tauri-action in GitHub Actions
I dont have w3m installed, It could be defaulting to that for you since "in terminal" things work
yeah, I don't have it installed intentionally, not sure why it's there
submitted a bug report, hopefully they'll have a fix
https://github.com/tauri-apps/tauri-action/issues/881
GitHub
xdg-open does not work in release artifacts produced by tauri-actio...
Hey @FabianLars 3 different, but related, functions of my application do not work when using the AppImage of my application produced by tauri-action in GitHub Actions, but work in AppImages produce...
TL;DR - don't use the AppImages from GitHub Releases.
Updates from me: openUrl doesn't open a window on my laptop either. xdg-open can open other urls fine. w3m wasn't installed; I installed it but didn't work as expected since that's a text-based browser. Symlinked w3m to google-chrome, didn't do anything either. I'm using the .deb from github, not the AppImage. I'll try with the AppImage as well but expect that not to work either.
I can also try on a fedora machine if that helps?
I'm wondering what binary it calls underneath, going to check with strace
oh, and "Open config directory" does work as expected for me, and brings up the file browser
Where is openURL coming from?
oh, interesting
so a different issue?
does using xdg-open in a Run Command action work for you @thomasvs?
not sure what you mean
Updates from me: openUrl doesn't open a window on my laptop eitherstill not sure what you mean
it's an event from a plugin
Thats what I meant, just where is "openURL" coming from/what does it mean
alright, this is the function we're looking at (I know BarRaider's plugins better than himself smh, found it instantly)
where did you find the code to that plugin? it wasn't in the github repo
let me try with a run command action
yep, that worked fine
in the installed directory
I've been reverse engineering this guy's plugins to get them to work for multiple years now, I know them pretty well
I knew the setup popup would be in the Setup/ dir, quickly tracked down
window.opener.openSpotifyAuth(), then searched the parent window (i.e. the property inspector)'s JS to find that functionoh I see the file, that part is just .js
so I can go to the URL myself, but the redirect to localhost:4202 fails because nothing is listening, which I assume is in some other part of the spotify plugin.
yep, the C# part of the plugin is closed-source (well, it all is, but the "benefit" of JS is that we can poke around with it)
🤷♂️
I enter a client ID and secret, press Next, it opens something in Firefox in the background that ends up at https://barraider.com/spotifysuccess, and then I see this
ok, so I'm assuming openUrl is hanging somehow on confirmation before opening a local 4202 socket.
let me check if I have firefox installed
I do, so that's not it either
no, the openUrl event is sent from the property inspector whereas the plugin is the one opening the socket, as well as there not being any confirmation of events sent back to plugins
yes - I was assuming it's the plugin opening the socket, but only after it gets some confirmation that openUrl succeeded. I can't verify without the code.
what OS are you on when you do this?
I’m on openSUSE Tumbleweed
there is no confirmation
weird, then I have no idea why the plugin wouldn't open that local socket while waiting for the browser window
Just installed opendeck on fedora 39. Have the same plugin unpacking issue, and i'm going to guess the 403 I get from your server has something to do with that. I'll see what the curl request tells me there.
I'll unpack it for now so I can test the topic of this thread
ok - unpacked by hand on Fedora 39. A restart did pick up the new plugin here without having to download another. And the spotify configuration opened a tab in chrome and completed successfully.
and it works. and neat - it shows the song art on the button, nice touch.
I wonder if I can copy plugin config over from one machine to the other
So that doesn't work - it still opens up the authentication flow. Any idea why the barraider spotify plugin wouldn't take the copied config? is there another place in the config dir I need to change smth to use that settings file?
now that I'm playing with the fedora machine more, every time I start opendeck or every time I add a plugin, it starts up the authentication flow again, but seems to skip through it
what exactly did you copy?
com.barraider.spotify.sdPlugin.json in settings
you would need to copy the plugins's settings from
<config dir>/settings/com.barraider.spotify.sdPlugin.json as well
ah
not sure then
yeah, it does that, but do you mean add a new action? not pluginyes, action, sorry.
I believe the AppImage issue - which developers of other Tauri apps have confirmed is a Tauri issue - is now either fixed in Tauri v2 (haven't tested yet) or still blocking on upstream Tauri, so that is "solved" on the OpenDeck side of things
As for @thomasvs's issue I believe that was an issue with the OBS plugin executable not starting due to Wine Mono not being installed with Wine on Debian-based distros, so that's solved too
Let me try the newest app image
im getting the same behavior, so must still be blocked somewhere.
It also smooshes the buttons together lol
yeah ok, still blocked in Tauri then
not sure about the smooshing lol