Web storage apis (localStorage, sessionStorage, webSQL, indexedDB, cookies) are disabled // activating the "standard" mode for the web3:// scheme

[nand2]

By default web storage apis (localStorage, sessionStorage, webSQL, indexedDB, cookies) are disabled for non standard schemes.
To activate this, I need to tell Chromium that web3:// is a scheme that follows what RFC 3986 calls "generic URI syntax". This is the standard mode. That is what we aim for, so I am activating it.
When I do that, extra behaviors and checks are added.
One behavior is : if it finds an hexadecimal number starting with "0x" in the host part of the URL, it considers that it is an IP address. And because ethereum address are much bigger than IP address, then it returns ERR_INVALID_URL, and it never enters the custom web3:// code.
This is at a deep level, inside the GURL library of chromium, that do the URL parsing.

So this breaks all URLS like web3://0x5a985f13345e820aa9618826b85f74c3986e1463/ : the code that handle the web3:// is not reached.

So far, I haven't found workarounds: the URL intercepts and rewrite/redirect functionalities of electron are done after the URL check.

Additionally, I can see the same type of problem for the :<chainId> : I have some librairies that break when chainId > 65536, because a standard port is not expected to go higher. (Sepolia is 11155111)

Long term, if we want the big browsers to integrate web3://, it needs to not be too difficult to them. We need to behave like standard URLs, it's difficult to expect them to change their core URL parsing code. So shall we update the host format of the web3:// protocol?

Maybe:
web3://8bb9a8baeec177ae55ac410c429cbbbbb9198cac/ instead of web3://0x8bb9a8baeec177ae55ac410c429cbbbbb9198cac/ ;
web3://11155111-8bb9a8baeec177ae55ac410c429cbbbbb9198cac/ instead of web3://0x8bb9a8baeec177ae55ac410c429cbbbbb9198cac:11155111/ ?
So, removing the "0x" and moving the chain id as a prefix?

[nand2]

To reproduce : activate the standard mode by changing :

{ scheme: 'web3', privileges: { supportFetchAPI: true } },

to

{ scheme: 'web3', privileges: { standard:true, supportFetchAPI: true } },

in
protocol.registerSchemesAsPrivileged([
in example/main.js.

Case 1/
Try to load :
web3://0x5a985f13345e820aa9618826b85f74c3986e1463:5/tokenHTML/1
You'll see in the console :

did-fail-load -300 ERR_INVALID_URL

Case 2/
Try to load :
web3://terraformnavigator.eth/
It will load the main webpage, but the images won't load, because they are in the web3://<ethereumAddress>/ format.

[nand2]

There is some URL interceptors (webRequest.onBeforeRequest -- https://www.electronjs.org/docs/latest/api/web-request ) but unfortunately they are triggered after the URL check described earlier that trigger the ERR_INVALID_URL error, so it stops before it reach them, so I cannot use them.

[nand2]

Bug filled at electron : electron/electron#37894

[nand2]

Electron rejected it as the issue is from the Chrome URL lib
Filled a bug at chrome : https://bugs.chromium.org/p/chromium/issues/detail?id=1441043
And managed to make a patch which should be conceptually acceptable at : https://chromium-review.googlesource.com/c/chromium/src/+/4494223