feat(`forge script`): add browser wallet support to `forge script`

[PatrickAlphaC]

Component

Forge

Describe the feature you would like

When deploying contracts, using forge create --browser is great, but it doesn't allow me to use the deploy script that I have tested. It could be great if I could run forge script myScript --browser so that I could run my tested deploy script with a browser wallet.

Additional context

No response

[mablr]

Hey @zerosnacks, if you haven't started to work on this internally, I'd be happy to help.

I guess we simply need the same browser-related flags in MultiWalletOpts as you recently added in WalletOpts.

[zerosnacks]

Hey @zerosnacks, if you haven't started to work on this internally, I'd be happy to help.

I guess we simply need the same browser-related flags in MultiWalletOpts as you recently added in WalletOpts.

There is possibly some more complexity involved to send & sign multiple transactions in a staged fashion but would be amazing if you could look into it! 😀

[gakonst]

if we use Porto accounts in the --browser flows as I originally suggested multiple txs are no problem as we support batching

[mablr]

Ok I explored deeper all the layers involved, forge create --browser is actually buggy since the brower's custom flow w/ send_transaction_via_browser is not used.

So I made a draft that seems to work for scripts involving multiple tx calls (checked w/ metamask).

But it appears that create fail because "to" field is null in transaction request.
For instance here is result for the Counter script:

../foundry/target/debug/forge script script/Counter.s.sol --rpc-url http://127.0.0.1:8545 --broadcast --browser

I think this should be fixed on the webapp side.

Then I need to figure out if it's necessary to force sequential execution of the scripts. (probably not)

Finally, it could be beneficial/necessary to think about UX improvement to handle multiple signers in the browser wallet...

if we use Porto accounts in the --browser flows as I originally suggested multiple txs are no problem as we support batching

Btw this seems very promising, I guess it would involve a 3-folded refactor to really benefit from porto's capabilities and separate from metamask flow : BrowserWallet webapp/server and script broadcast logic. It would also be great if the webapp allowed to configure the rpc url for Porto.