1.2.20: internal spinner rotating outside its container

[matildepark]

Describe the bug

On Google Chrome.

To Reproduce Steps to reproduce the behavior:

1. Click "Submit" on a button running 1.2.20.

For a way to check, I've pushed my branch bumping indigo-react to urbit/urbit, branch mp/landscape/indigo-bump.

Note — If you hit some weird crash on staging the prerequisite packages on attempted install, you'll need to do the following from the pkg/interface folder to clear the npm cache across the various packages (two commands):

rm -rf node_modules && cd ../npm/api && rm -rf node_modules && cd ../eslint-config && rm -rf node_modules && cd ../http-api && rm -rf node_modules && cd ../../interface && npm cache clear —force
cd ../npm/api && npm i && cd ../eslint-config && npm i && cd ../http-api && npm i && cd ../../interface && npm i

If you don't get that crash, but a crash on processing ts files in the api folder you'll need to just go to the npm folder and npm i on all the packages in there.

Expected behavior

A spinner.

[g-a-v-i-n]

weird

[matildepark]

OK I merged https://github.com/urbit/urbit/pull/4772 into the indigo-bump branch so it shouldn't require those insane incantations.

[g-a-v-i-n]

Can you verify this spinner is imported from @lton/indigo-react? It would be helpful to have a code line as well.

[matildepark]

I think it’s here, since it’s the async button component:

https://github.com/urbit/urbit/blob/bb3661975deab9bc618dbb99167fe7193a042435/pkg/interface/src/views/components/StatelessAsyncButton.tsx#L36

You can use any save button in system preferences to simulate.

[g-a-v-i-n]

Resolved in 1.20.21