Just in case its helpful, worked on a couple potential FE tests -> For ThemedApp.test.tsx

  import { act } from "react-dom/test-utils"
  import FontFaceDeclaration from "./components/core/FontFaceDeclaration"

  const mockCustomThemeConfig = {
    primaryColor: "#1A6CE7",
    backgroundColor: "#FFFFFF",
    secondaryBackgroundColor: "#F5F5F5",
    textColor: "#1A1D21",
    widgetBackgroundColor: "#FFFFFF",
    widgetBorderColor: "#D3DAE8",
    fontFaces: [
      {
        family: "Inter",
        url: "https://rsms.me/inter/font-files/Inter-Regular.woff2?v=3.19",
        weight: 400,
      },
    ],
  }


  it("handles custom theme sent from Host", () => {
    const wrapper = mount(<ThemedApp />)
    
    let fontFaceComponent = wrapper.find(FontFaceDeclaration)
    expect(fontFaceComponent.exists()).toBe(false)

    const props = wrapper.find(AppWithScreencast).props()
    act(() => {
      props.theme.setImportedTheme(mockCustomThemeConfig)
    })
    
    wrapper.update()

    const updatedTheme: ThemeConfig = wrapper.find(AppWithScreencast).props().theme.activeTheme
    expect(updatedTheme.name).toBe(CUSTOM_THEME_NAME)
    expect(updatedTheme.emotion.genericColors.primary).toBe(mockCustomThemeConfig.primaryColor)

    fontFaceComponent = wrapper.find(FontFaceDeclaration)
    expect(fontFaceComponent.exists()).toBe(true)
    expect(fontFaceComponent.props().fontFaces).toEqual(mockCustomThemeConfig.fontFaces)
  })

For withHostCommunication.test.tsx

const mockCustomThemeConfig = {
  primaryColor: "#1A6CE7",
  backgroundColor: "#FFFFFF",
  secondaryBackgroundColor: "#F5F5F5",
  textColor: "#1A1D21",
  widgetBackgroundColor: "#FFFFFF",
  widgetBorderColor: "#D3DAE8",
}

  it("can process a received SET_CUSTOM_THEME_CONFIG message", () => {
    act(() => {
      dispatchEvent(
        "message",
        new MessageEvent("message", {
          data: {
            stCommVersion: HOST_COMM_VERSION,
            type: "SET_CUSTOM_THEME_CONFIG",
            theme: mockCustomThemeConfig,
          },
          origin: "http://devel.streamlit.test",
        })
      )
    })

    wrapper.update()

    const theme = wrapper.find(TestComponent).prop("theme")
    expect(theme.setImportedTheme).toHaveBeenCalledWith(mockCustomThemeConfig)
  })

Looks like only remaining test failure is in App.tsx for the "does nothing if the custom theme received from server has a matching hash" test -> the hash comparison is failing, so addThemes and setTheme are called.
This is a result of the customThemeConfig constructor initializing a default empty array for the fontFaces key, while the NewSession constructor doesn't include an empty fontFaces key at all. This is a protobuf issue and Ken/I don't believe it will be problematic, so just updating the test should be okay.
In NEW_SESSION_JSON object, resolve per below:

  const NEW_SESSION_JSON = {
    config: {
      gatherUsageStats: false,
      maxCachedMessageAge: 0,
      mapboxToken: "mapboxToken",
      allowRunOnSave: false,
      hideSidebarNav: false,
    },
    customTheme: {
      primaryColor: "red",
      fontFaces: [],
    },
// .... rest of the stuff here

c3e6026

Thanks a lot for looking into this, @mayagbarnes! This test had been fixed on c3e6026.

Let me know if you need anything else here!

Also when I test locally and hard refresh (browser refresh button vs just hitting R to re-run), the theme reverts back to our standard theme vs restoring the theme sent with postMessage. This is intended behavior/unproblematic for SIS right?

Also when I test locally and hard refresh (browser refresh button vs just hitting R to re-run), the theme reverts back to our standard theme vs restoring the theme sent with postMessage. This is intended behavior/unproblematic for SIS right?

@sfc-gh-tteixeira or someone on the SiS team might be able to confirm with a bit more detail than me, but my understanding was that the way SiS infrastructure works, the app will be reloaded every time you access it, and we don't have any caching mechanism for themes there, so the message will always be re-sent, causing the app to update the theme accordingly (tough leading to other potential problems, such as flickering when the theme updates).

Also when I test locally and hard refresh (browser refresh button vs just hitting R to re-run), the theme reverts back to our standard theme vs restoring the theme sent with postMessage. This is intended behavior/unproblematic for SIS right?

The localStorage cache is not required for SiS. It would be great if it worked, but also OK if it doesn't. (And even if it worked, there are questions about when should we clear it. Do we do something smart there today, clearing based on the hash of the config or something?)

Do we do something smart there today, clearing based on the hash of the config or something?

Ah, we do actually reapply the theme when the hash of the theming config received from the server changes (see the processThemeInput function in App.tsx), and this is probably what's breaking local theme caching with what we receive from postMessage since the server-defined theme will always be different.

Ok, I'm seeing checkmarks next to both your names in Github, and looking at the discussion it feels like everything is resolved, so I'll just go ahead and merge.

Some future work:

• Figure out caching. See this message from Vincent
• Figure out a good behavior for when the theme is set by the user in config.toml
• See if flicker from this solution is bad in practice. If so, implement solutions for that!