tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
84.52k stars 2.54k forks source link

Calling a package's function causes "OperationError: The operation failed for an operation-specific reason > (anonymous function)" #5825

Open AustinFoss opened 1 year ago

AustinFoss commented 1 year ago

Describe the bug

My goal was to implement a desktop IPFS app using JS-IPFS that could ultimately be ported to mobile after seeing last week's alpha announcement.

I started with the Nuxt3 framework but ran into some other errors, seemingly related to Nuxt's router. So I switched to the vanilla-ts template generated using yarn create tauri-app for my starting point.

When trying to call the function creat() from the 'ipfs' npm package, lines 16-27 of the 'main.ts' file, I get a very non-descriptive error message.

Because this works in a browser just fine I'm not to sure what's going on in the Tauri side, whether it's Tao or Wry related.

Any insight would be greatly appreciated!

Reproduction

  1. Clone my test repo: https://github.com/AustinFoss/tauri-ipfs
  2. cd into the directory, yarn install && yarn tauri dev to run the basic demo
  3. You will see one extra button added to the starter template 'Init IPFS'
  4. Right click the Tauri app window and select 'inspect element'
  5. Click 'Init IPFS' and observe the error

Expected behavior

If you run yarn dev and open the server address, mine is 'http://127.0.0.1:1420/', in a browser you can observe the proper output in the console. Something like:

IPFS2 {hashers: Multihashes, bases: Multibases, name: NameAPI, ipns: IPNSAPI, preload: ƒ, …}

Much larger when expanded.

Platform and versions

Environment › OS: Pop!_OS 22.04 X64 › Node.js: 16.15.1 › npm: 8.13.1 › pnpm: Not installed! › yarn: 1.22.19 › rustup: 1.25.1 › rustc: 1.65.0 › cargo: 1.65.0 › Rust toolchain: stable-x86_64-unknown-linux-gnu

Packages › @tauri-apps/cli [NPM]: 1.2.2 › @tauri-apps/api [NPM]: 1.2.0 › tauri [RUST]: 1.2.2, › tauri-build [RUST]: 1.2.1, › tao [RUST]: 0.15.7, › wry [RUST]: 0.23.4,

App › build-type: bundle › CSP: unset › distDir: ../dist › devPath: http://localhost:1420/ › bundler: Vite

App directory structure ├─ .git ├─ .vscode ├─ src-tauri ├─ node_modules └─ src

Stack trace

[Log] OperationError: The operation failed for an operation-specific reason (main.ts, line 18)
(anonymous function)

[Log] Trace
    (anonymous function) (main.ts:19)
    (anonymous function)
        ...

Additional context

IPFS has some extra info from their examples how to configure Vite to bundle the package: https://github.com/ipfs-examples/js-ipfs-examples/tree/master/examples/browser-vite

I adapted their vite.config.js for use in my project so the default vite.config.js in my repo has some changes. Although is seems the only one that's needed after Vite 4 was:

  define: {
    'process.env.NODE_DEBUG': 'false',
    'global': 'globalThis'
  },
FabianLars commented 1 year ago

in a browser you can observe the proper output in the console

Can you check epiphany / gnome web too? It's a browser based on webkitgtk which we use as the webview.

Otherwise the only potentially related issue i found was this: https://github.com/ipfs/js-ipfs/issues/3878#issuecomment-1015815324 - it's for safari on ios, but that's still webkit so i think it's worth to try the workaround mentioned there.

AustinFoss commented 1 year ago

I just tried it with epiphany and got the same result.

I wasn't sure how to implement the same logic check for isSafari so I independently checked it for all 3 cases on both the Epiphany Browser and the Tauri view. According to these types, the algorithm property of the options object passed to create() can be any of these 3:

export const Ed25519 = 'Ed25519'
export const RSA = 'RSA'
export const secp256k1 = 'secp256k1'

export type KeyType = typeof Ed25519 | typeof RSA | typeof secp256k1

All three work in Brave (what I'm testing with), as well as firefox, but all 3 fail in epiphany and the tauri view.

Does epiphany have a problem with those 3 encryption algorithms?

AustinFoss commented 1 year ago

Depending on where that info leads I could link this issue over in that closed issue in the js-ipfs repo, or the gnome epiphany gitlab repo.

FabianLars commented 1 year ago

It sounds like a webkitgtk issue to me if it works fine in Safari. so either the webkitgtk repo or the ipfs repo or both.

epiphany is basically in the same place as we are. they just use webkitgtk