concordium / concordium-browser-wallet Goto Github PK

Bug Description
The wallet does not support using bigint as part of a parameter for a smart contract, meaning it is impossible to use integers that are larger than supported by number. This example is showcasing it using a contract address which uses u64, but the issue also applies for contracts just using u64 as part of their parameter.

Steps to Reproduce
Use a bigint for any parameter which can be bigger than number, such as u64 or index in a smart contract address.
An example can be found in the branch bigint-in-sc-params

Expected Result
Success

Actual Result
Error produced by the wallet API

Description

The background image on wCCD.testnet.concordium.com is almost 12MB.

This slows down loading and makes for bad user experience. There is no reason to have such a large image and we should reduce the size.

Bug Description

Window.concordium is undefined "sometimes". The browser wallet seems to not inject it.

The issue appears when a page is loaded in a new tab for the first time. After refreshing the page, window.concordium is defined and the connection to the browser wallet can be established.

The issue has been observed on the following front ends "sometimes":

• https://cis2-sponsored.testnet.concordium.com/
• https://sctools.mainnet.concordium.software/
• https://wallet-test-bench.testnet.concordium.com/
• Track-and-trace: Concordium/concordium-dapp-examples#54

Steps to Reproduce

• It seems to happen "sometimes" the first time you open a page in a tab that the window.concordium is not set.
• It DOESN't seem to happen if the page is refreshed, the developer console is open or the page is loaded from a bookmark.

Expected Result

Window.concordium is defined. Connecting to the wallet works.

Actual Result
windows.concordium_undefined2.webm

Bug Description

When I try to follow the instructions to install and run the piggy bank example, I get an error when I run yarn build:all.

Steps to Reproduce
Open the repo.
Navigate to the piggy bank example.
Run yarn. Result is OK if I ignore checksum.
Run yarn build:all and get error:

PS C:\concordium-browser-wallet\examples\piggybank> yarn build:all
➤ [wccd]: Process started
➤ [wccd]: (node:15116) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
➤ [wccd]: (Use node --trace-warnings ... to show where the warning was created)
➤ [wccd]:
➤ [wccd]: dist\index.js 4.5mb
➤ [wccd]: dist\index.css 3.2kb
➤ [wccd]:
➤ [wccd]: Done in 317ms
➤ [wccd]:
➤ [wccd]: dist/index.html - 524
➤ [wccd]: HTML Plugin Done in 88ms
➤ [wccd]: 'cp' is not recognized as an internal or external command,
➤ [wccd]: operable program or batch file.
➤ [wccd]: command not found: cp
➤ [wccd]: Process exited (exit code 127), completed in 2s 976ms
➤ The command failed for workspaces that are depended upon by other workspaces; can't satisfy the dependency graph
➤ Failed with errors in 2s 983ms

Expected Result

Should be able to run the example on all platforms.

Actual Result
cp command is unknown in Windows.

Søren B. Zeppelin knows about this issue.

Bug Description

The injected script attempts to compile and instantiate WebAssembly (seems to be from the rust-bindings package), which fails when a website uses a Content Security Policy which does not allow for running WebAssembly.
This results in several error messages from repeated attempts at compiling the WebAssembly module, which in turn produces a lot of work for the garbage collector.

This might be causing some websites to feel 'laggy', as the garbage collector tries to clean up.

Steps to Reproduce

With the browser extension installed, navigate to a website with a strict Content Security Policy such as twitter.com. The errors can be found in the browser developer console.

Versions

• BrowserWallet 1.5.0
• Chromium 122.0.6261.128

• Test new unreleased BW with current dAps
• Regression test the dApps after the BW was published

Bug Description

The function isEuCountrySet does not correctly check if the set of countries equals the set of EU members. A list containing a repetition of a single EU member country will also resolve to true when it shouldn't.

Steps to Reproduce

Use the proof explorer (https://web3id-proof-explorer.testnet.concordium.com/) to generate a set proof where the set is

DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK,DK

Expected Result

The UI should display this as proving that the nationality is in the exact list provided, and thereby not triggering any special EU membership UI.

Actual Result

The UI will display this as proving that the nationality is in the EU.

Versions

• Software Version: 1.4.2

Description
The Concordium provider that you get from detectConcordiumProvider has a nice interface for contract init and update where it automatically serializes the parameters using a provided schema. But when you want to invoke a contract, you have to go down one level of abstraction and use jsonRpcClient.

It would be great if we could add a helper method for invoking contracts at the same level of abstraction as init and update.

Current

With contract updates, we can provide a JSON parameter and a module schema as a string

 client
.sendTransaction(
    currentAccountAddress,
    concordiumSDK.AccountTransactionType.Update,
    {
        amount: new concordiumSDK.CcdAmount(0n),
        contractAddress: {
            index: contractIndex,
            subindex: 0n,
        },
        receiveName: 'voting.vote',
        maxContractExecutionEnergy: 3000n,
    },
    votingOption,
    rawModuleSchema,
)
.then((msg) => alert(`Successfully sent vote with transaction hash: "${msg}"`))
.catch(alert);

But for invocations, you have to use the json rpc client directly, which is at a lower level of abstraction.

Here, you have to serialize the parameter and deserialize the return value manually.
You also have to specify contract and entrypoint as two separate parameters, instead of a receive name (<contract_name>.<entrypoint_name>).

const inputParams = serializeUpdateContractParameters("voting.view", { my: "JSON parameter"}, rawModuleSchema);

client.getJsonRpcClient().invokeContract({ // Using json rpc client
    contract: { index: BigInt(contractIndex), subindex: BigInt(0) },
    method: 'voting.view',
    parameter: inputParams
})
.then((viewResult) => {
    let returnValue = concordiumSDK.deserializeReceiveReturnValue(
        concordiumSDK.toBuffer(viewResult.returnValue, 'hex'),
        concordiumSDK.toBuffer(rawModuleSchema, 'base64'),
        "voting",
        "view", // NOTE: Here it is just the entrypoint name, i.e. the contract name is not prepended.
        concordiumSDK.SchemaVersion.V2
    );
})
.catch(alert);

Suggestion

client.invokeContract({                  //  <-- Helper function directly on client
    contract: { index: BigInt(contractIndex), subindex: BigInt(0) },
    method: 'voting.view',
    parameter: { my: "JSON parameter" }, // <-- Directly provide json schema
    rawModuleSchema                      // <-- And schema
})
.then((viewResult) => {
    // The viewResult is the deserialized return value.
    let field_a = viewResult.a;
})
.catch(alert);

When the browser wallet is released with the updated wallet API, the examples should be updated to point to the official release of @concordium/browser-wallet-api-helpers and @concordium/react-components.

Task description

Create an example demo front-end for the eSealing service.

Corresponding smart contracts:
Concordium/concordium-rust-smart-contracts#197
Concordium/concordium-rust-smart-contracts#207

The front-end should support the following two flows with the browser wallet (or wallet connect):

• Upload a file from the computer => register its file hash in the smart contract via the Concordium Browser wallet
  Similar to:
  http://filesealing.newtrust.co.s3-website-us-east-1.amazonaws.com/

• Upload a file from the computer => retrieve the time-stamp and witness (sender_account) that registered the file hash
  Similar to:
  https://timestamp.northstake.dk/

• Regression test baking& delegation
• Include new flows for moving the stake
• New cooldown logic

Bug Description

Whenever the page URL changes, the inject.js instantiates WebAssembly. This causes the tab to quickly run out of memory and start lagging if the URL changes frequently.

Steps to Reproduce

• Install Concordium Browser wallet 1.5.1
• Go to Google Maps
• Explore the map: move around, switch modes, watch photos, have a 5-min journey

Expected Result

Google Maps remain usable.

Actual Result

After lots of URL changes due to moving coordinates and other map activity, the tab goes out of memory and the garbage collector starts using lots of CPU. Out of memory errors caused by wallet's inject.js are logged into the console. Google Maps become sluggish and unresponsive until the tab is closed or reloaded.

Versions

• Software Version 1.5.1
• OS Windows 11
• Browser Edge 122.0.2365.92 (Official build) (64-bit)

Task description

All our dapp examples in this repository hardcode

            maxContractExecutionEnergy: Energy.create(30000n),

which is not ideal user experience. Since these examples are also used by others as starting points they should promote best practices.

Bug Description
Im trying to use Concordium Browser Wallet API to Initialize a contract which i have created
https://github.com/chainorders/concordium-rwa/blob/eb66870206fef16c1a9c48147161b93c5ead8233/contracts/identity-registry

The code that im using to Initialize is

const initialize = () => {
		detectConcordiumProvider().then((provider: WalletApi) => {
			provider.getMostRecentlySelectedAccount().then((account?: string) => {
				if (!account) {
					setError("No account selected");
					return;
				}
				provider
					.sendTransaction(
						AccountAddress.fromBase58(account),
						//@ts-expect-error Invalid types provided by base library
						AccountTransactionType.InitContract.toString(),
						{
							amount: 0,
							moduleRef: ModuleReference.fromHexString(
								"f081dce35e8900fb99eb78b36bd221e649d764716ee366fc392d0fd9751ed0d6"
							),
							initName: "init_rwa_identity_registry",
							maxContractExecutionEnergy: 9999,
						},
						undefined,
						undefined,
						undefined
					)
					.catch((e) => setError(e.message));
			});
		});
	};

Issues with this code / library

1. On removing the line //@ts-expect-error Invalid types provided by base library the library gives type errors when using with typescript. Even replacing this line AccountTransactionType.InitContract.toString() with "1", 1 does not help
2. Upon sending the transaction the browser wallet popup blanks out. See the attached video for an example. With the errors in the extension console Uncaught Error: The provided type does not have a handler: 1

Steps to Reproduce

1. use the mentioned code to send a transaction

Expected Result
The transaction should be sent

Actual Result
Screencast from 26-12-23 04:18:28 AM IST.webm

Versions

	"dependencies": {
		"@concordium/browser-wallet-api-helpers": "^3.0.0",
		"@concordium/web-sdk": "^7.1.0",
		"@emotion/react": "^11.11.1",
		"@emotion/styled": "^11.11.0",
		"@fontsource/roboto": "^5.0.8",
		"@mui/icons-material": "^5.15.1",
		"@mui/material": "^5.15.1",
		"@mui/styles": "^5.15.1",
		"@reduxjs/toolkit": "^2.0.1",
		"react": "^18.2.0",
		"react-dom": "^18.2.0",
		"react-router-dom": "6"
	},

Wallet Version
Version 1.2.1

• Software Version
• OS
• Browser
• Mobile device, if applicable

Protocol 7 introduces changes in how stake cooldown is handled.

These need to be reflected in the wallet.

Task description

Create a front-end and back-end for the sponsored tx example.

Sub-tasks

• Register a public key.
• Calculate message based on the parameters provided by the user.
• Field/Logic to request a signature from the browser wallet or walletConnect.
• Flow to submit the sponsored tx to the backend.
• Query the up-to-date nonce from the smart contract.
• Add a flow for people to mint tokens to their addresses so they can test the transfer flow. Unprotect the mint function in the smart contract. Use a counter in the smart contract to increase the tokenID.
• Use the signing features from the Concordium browser wallet.
• Create a backend that signs and sends the sponsored transaction to the chain to pay for the transaction fee.

Bug Description
While generating the proof app allows to pick any account tied to identity 1, but if there are multiple identities and accounts you can't see them.
Steps to Reproduce

1. Add another identity and create an account
2. Connect to the platform and click Verify
3. Look for the newly created account
   Expected Result

Actual Result

Versions

• Browser

Bug Description
The QR code encoding an account address is hard to scan, especially in dark mode. The reason for that is that QR codes must include a white border, called quiet zone. According to the QR code specification, the width of that white border should be at least 4 times the size of a "module" (i.e., the smallest squares in the QR code).

Bug Description

The browser wallet allows selecting expired credentials when producing proofs.

Steps to Reproduce

Go to https://web3id-proof-explorer.testnet.concordium.com/
Select a simple statement about account credentials, e.g., "reveal first name".
When asked which account to use in the wallet select a credential that is expired.

Expected Result

I am unable to select the expired credential.

Actual Result

I am able to select the expired credential, and the proof is then rejected.

Versions

• Software Version: 1.5.0

Task description

Some users have requested a button to open the browser wallet in a tab instead of as the extension popup. This task will a button to the settings page that will open such a tab. The fullscreen view will not contain any custom views of the wallet, and will just be a centered version of what is currently shown in the extension popup. This can then later be extended to e.g. include a fullscreen onboarding flow if needed.

Sub-tasks

• Add button to open fullscreen view of the browser wallet.
• Make modifications to the CSS so that the fullscreen view is centered.
• Make modifications to the CSS to ensure that nothing is broken in the fullscreen view (menu dropdowns do not work out of the box when making the fullscreen view).

Bug Description
Token Metadata De-serialization error in the method
https://github.com/Concordium/concordium-browser-wallet/blob/main/packages/browser-wallet/src/shared/utils/token-helpers.ts#L61

The Method linked above should also take into account the optional Hash value which can be present in the Token Metadata

Steps to Reproduce
Using the URL
https://chainorders.github.io/concordium-nft-tutorials/index.html#/mint-multi-batch

1. Click "Deploy New" (This will initialise a new CIS2-Multi contract).
2. Enter Pinata JWT and Click "Connect"
3. Click Upload and Select at-least 3 Image Files
4. Click "Set Token Id" in all the 3 boxes
5. Click "Upload Image" in all the 3 boxes
6. Click "Create" On all the 3 boxes
7. Set Any Quantity in all the 3 boxes
8. Click "Done" at the bottom
9. Click "Mint"
10. Upon See the Alert Message "All Minted"
11. Open the Wallet and try to "Look for Tokens" in the recently initialised contract.
    You should see the error in the wallet console.

Alternatively You can use the contract present here. Initialize it and mint atleast 3 Tokens with Metadata Hash

Expected Result
Tokens should be added to the wallet

Actual Result
Error in console and wallet doesnt appear to be doing anything

Uncaught (in promise) RangeError: Trying to access beyond buffer length
    at _B (index.js:1127:36)
    at WA.readUint16LE.WA.readUInt16LE (index.js:1173:18)
    at QYA (token-helpers.ts:69:28)
    at token-helpers.ts:125:29

Versions

• Software Version : 0.9.6
• OS : Ubuntu
• Browser : Chrome
• Mobile device, if applicable

Task description
Complete tests.
Sub-tasks

• Regression tests: 26 accounts, run through dApps.
• Smoke test.

Bug Description
The wallet API is injected multiple times in every website, sometimes seen up to 8 times on load and even more after that.

Steps to Reproduce

• Add breakpoint/logpoint in the injected script using the developer tools in the browser.
• Navigate between channels on slack.

Expected Result
The injected script is only executed once per site.

Actual Result
The injected script is executed several times and on user interaction as well.

Versions

• BW 1.5.0
• Linux
• Chromium

Bug Description
This depends on the implementation of Concordium/concordium-node-sdk-js#344. Upgrading the dependency to the common SDK with this change included should fix the issue.

Steps to Reproduce

• Go to https://github.com
• Open developer tools (F12)

Expected Result

• No WASM compilation error is shown

Actual Result

Versions

• Software Version: 1.5.1
• OS: macOS
• Browser: chrome

Bug Description
I'm trying to follow the build instruction in order to run the wCCD example, but the yarn build command fails.

Steps to Reproduce

• Clone the https://github.com/Concordium/concordium-browser-wallet repository
• Run yarn in the root directory, wait for all the dependencies to be installed
• Go to the examples/wCCD directory
• Run yarn, wait for all the dependencies to be installed
• Run yarn build

Expected Result
The app is built successfully and can be launched by yarn start

Actual Result
The build fails with the following error:

✘ [ERROR] Could not resolve "@concordium/browser-wallet-api-helpers"

    ../../node_modules/@concordium/wallet-connectors/dist/BrowserWallet.js:13:45:
      13 │ ..._wallet_api_helpers_1 = require("@concordium/browser-wallet-api-helpers");
         ╵                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "@concordium/browser-wallet-api-helpers" as external to exclude
  it from the bundle, which will remove this error. You can also surround this "require"
  call with a try/catch block to handle this failure at run-time instead of bundle-time.

The build output contains the incomplete index.html file, which does nothing when started with yarn start

Versions

• Software Version: a834753
• OS: Windows 10
• Browser: MS Edge
• Mobile device, if applicable: No

Using votingIndex is not displayed in the browser wallet:

Concordium/concordium-rust-smart-contracts#189 (comment)

When a voter gets the link to an election if the wallet isn't connected the options are blank. If the voter votes, there is a transaction fee. The voter has to refresh after connecting to the wallet to see the options.

Expected Result

A warning when the voter opens the election link if the wallet isn't connected before showing options.

Bug Description

If the decimals field in the metadata is a string instead of an integer, the browser wallet shows a blank screen.

Steps to Reproduce

1. Add a token where the metadata has "decimals": "not a number"

Expected Result
Not sure, but perhaps the token should be displayed with 0 decimals. A warning could also be shown.

Actual Result
Blank screen of death:

Notes for reproducing
I've created a modified version of our wCCD contract in which you can update the metadata URL via the updateUrl entrypoint.

The module is deployed on testnet with reference:
058bf1d66a6b8fc258faeac69d633a04fd74cf3832dcdbe7a1252e7b23b320fc.

I've created a number of test metadata files on gist (see the different revisions). You need to click the raw button to get the actual file (and link) that should be passed to updateUrl.

https://gist.github.com/Bargsteen/e1ebac26ee47d601c7d816c0f839261c/b68d8cf91ad0d3f816fd1d679626bcebb20edfb7

Versions

• Software Version: 0.8.0
• OS: macOS
• Browser: Arc browser

Task description
Instead of the proxy-implementation-upgradable wCCD contract, we will use the natively-upgradable wCCD contract in the future. Update the front-end to work with this smart contract.

Bug Description

I have an react application in which I've implemented concordium sdk it was working well but when I have started migrating it to nextjs it is not working and it throws a error called Syntax Error: Unexpected token 'export' for concordium/browser-wallet-api-helpers package and can't resolve '@concordium/web-sdk' for @concordium/web-sdk package

Description

When importing the tokens from a contract address into the wallet, and the fetched metadata in the smart contract has a wrongly computed hash (or file at the url has changed) for all the tokens, the error returned by the browser wallet is No valid tokens found in contract.

Users seem to have difficulties identifying the problem. The problem is a mismatch of the hash in the tokenMetadata as stored in the smart contract vs. the freshly computed hash from the current file linked in the metadata url. It would be good if the browser wallet could return an error No valid tokens found in contract. TokenMetadata has an invalid checksum/hash value similar to the Android wallet.

In addition, some contracts might have both valid and invalid tokens. The browser wallet only shows the valid tokens (a note that some invalid tokens have been found would be useful as well, instead of silently ignoring invalid tokens).

Steps to Reproduce
e.g. Contract 8432 has an invalid hash in the token metadata (the contract has only one token). Open the manage tab in the browser wallet and try to import the tokens from the contract. Observe the error message. Compare the results with the AndroidMobileWallet flow.

e.g. Contract 8418 has some valid and some invalid tokens (wrong hash in metadata). The browser wallet only shows the valid tokens but no message/error/warning that some invalid tokens exist in the contract.

Bug Description
If I try to set u8 value on testbench, I get an error. The same test case works with BW 1.4.1.

Steps to Reproduce

1. Connect bw 1.4.2 to test bench.
   2.Don't add any parameters, set u8 value.

Expected Result
Transaction finalized.

Actual Result
Error: The given transaction is not valid due to: TypeError: Cannot read properties of undefined (reading 'split').

Versions

• Software Version: 1.4.2

The current behavior of the browser extension is to inject a script on every website that the user visits. This effectively slow down every site the user visits, but also means the user grants access for the extension to inject and modify every site they visit, which is a lot to ask.
To my knowledge, the only point of the injected script is to expose the API of the browser wallet to sites like dApps.

I suggest the wallet instead expose this API using the chrome extension API for message passing, provide a 1-to-1 API for dapp developers in a library and then deprecate the injected script.

Removing the injected script would be a breaking change, so the dapps will need some time to migrate to the library first.

It would be both good user experience to suggest to add the newly wrapped token to the user's wallet, as well as a good example to demonstrate this functionality in an example app to spread its visibility.

The best user experience would be if

• the app submitted the wrap transaction
• waited until that is finalized
• after that suggested to add the wrapped CCD to the wallet.

In the interest of time a simpler option with a button that would just trigger addCIS2Tokens would be better than nothing.

Task description
It would be easier to maintain the running wCCD front-end and its docker images if we have clear versioning of the wCCD example project.

Sub-tasks

• Add versioning to the wCCD example project
• Add versioning to the docker image
• Add versioning to be displayed at the front-end

Task description
If a smart contract implements the CIS3 standard (sponsored transactions). The sponsored transaction message will be sent to the Concordium browser wallet to be signed by the user. Currently, when providing the schema to the browser wallet, it can decode the object except for the payload field which is an array of bytes.

Feature to be added to the browser wallet:
The browser wallet can also decode the payload field by looking up the parameter schema of the entry_point_name and using this schema to decode the payload. The payload is the input parameter that is sent to the entry_point_name.

CIS3 standard:
Concordium/concordium-update-proposals#41

1. Test new implementation
2. Regression tests
3. Release tests

Task description
Clean-up and add the voting example from the hackathon