Can't open html or any other associated file type if browsernaut is already running
Closed this issue · 6 comments
This is an issue with handling only url events instead of 'odoc' events. I had similar issue with my app and solved it this way
https://github.com/openscopeproject/TrguiNG/blob/master/src-tauri/src/macos.rs
Can you post some info on your system setup for this? OS version and intel/apple silicon would be a great start.
This works on my machine, it took a bit of messing around but using the tauri-plugin-deep-link plugin I was able to get this to work for me - see attached video.
browsernaut.mov
If you're seeing other behavior could you explain what it is that you're seeing?
I'm running macos 12.5.4 on a x86 vm.
If I double click html file in finder while browsernaut is not running it opens fine. But if it's running then I'm getting a "The document ... could not be opened. App can not open files in the ... format" error.
Hmm that's interesting. There are quite a few variables here that I can't account for however.
If there's anyway for you to test on a physical machine and on the most recent OS version (13.4.1) that would certainly help me narrow this down. Using those setting I'm able to open these files just fine whether or not Browsernaut is running, so I'm wondering if something changed from macOS 12 -> 13
Sadly I don't have access to a physical mac and I can't update the vm to 13 because then it breaks.
I only reported this because in my investigations of the issue FabianLars on tauri support discord pointed me to your repo for an example of working tauri app with file associations. However it didn't work for me with error described above. I checked if browsernaut has same issue and it does.
So I set out to properly implement apple 'odoc' event handling and that helped my case, I linked the code above if you want to do something like that. Or you can ignore this if it works for you ¯\_(ツ)_/¯
Huh this is interesting. I'll definitely be looking at your implementation when I get a few minutes.
Before closing this I do want to double check that it works on my x86 machine the same way it does here, if it does work I'll add an enhancement label here and circle back when I have a bit of time to work on "proper" odoc implementation.
Tested this on an intel machine and was able to confirm that it is working as expected on the latest macOS version. Added enhancement label to revisit in the future.