Gutenberg-mobile: Theme changes (colors) are not applied until you close and reopen the editor

[antonis]

Describe the bug
When you switch theme in the app the theme color palette does not change. This is reproduced both on iOS and Android.
~If you switch site and get back, the theme changes are applied.~
If you close the editor and reopen it, the theme changes are applied.

To Reproduce
Steps to reproduce the behavior:

1. Create a post/page
2. Add a block that has color palette (e.g. Cover or Buttons)
3. Check the available palette colors
4. Change the theme
5. Create a post/page
6. Add a block that has color palette (e.g. Cover or Buttons)
7. The available palette colors have not changed
8. ~Switch to another site~ Close the editor
9. ~Switch back to the original site~ Create a post/page
10. Add a block that has color palette (e.g. Cover or Buttons)
11. The available palette colors are now updated

Expected behavior
The palette colors should change (step 7) when the user changes theme

Screenshots
A video replicating the issue can be downloaded here.

Smartphone (please complete the following information):

• Device: iPhone SE 2020 (iOS 14), Pixel 2 XL (Android 11)

[chipsnyder]

Hey @antonis I have a question on what you're experiencing to make sure I'm seeing the same issue.
If I modify the repo steps to the below steps do you see the same behavior:

1. Create a post/page
2. Add a block that has color palette (e.g. Cover or Buttons)
3. Check the available palette colors
4. Change the theme
5. Create a post/page
6. Add a block that has color palette (e.g. Cover or Buttons)
7. The available palette colors have not changed
8. ~Switch to another site~ Close the editor
9. ~Switch back to the original site~ Create a post/page
10. Add a block that has color palette (e.g. Cover or Buttons)
11. The available palette colors are now updated

[antonis]

If I modify the repo steps to the below steps do you see the same behavior:

@chipsnyder I confirm that I see the same behavior with your steps. The second time I open the editor the theme is applied.
Switching site is not necessary but I was biased to believe that a refresh occurs only this way. I updated the issue.

[chipsnyder]

Awesome thanks @antonis it seems like this might be a case of the update event being lost as part of the bridge call. Now that we've done some work to improve that communication I'll look to see if there is a better API we can use to ensure those payloads go through

[chipsnyder]

Sharing here what @antonis and I both discovered. It seems the theme is being passed to the JS side successfully and is correct up to where it gets applied to the settings. So this looks to be a change on the JS side

[chipsnyder]

For the theme showing up with the wrong values, it looks like there might be a timing issue. If the new theme downloads and calls update before the editor loads then the editor will load with the correct theme then revert back to the wrong values do to the initial theme finally being passed.