#8219: don't let frames control sidebar panel via setPanels

[twschiller]

What does this PR do?

• Part of MV3 sidebar gets into a state where it's showing no panels #8219
• Fixes bug where frames were passing empty panel array to the sidebar

Discussion

• Here's the line that on page reload/redirect that causes the panels to get cleared out: https://github.com/pixiebrix/pixiebrix-extension/pull/8225/files#diff-66427d06cd5d1cb09f2785e19851e9257f75f98665d26343ecb38bc94e7ba7d9R108

Demo

• https://www.loom.com/share/ab099740afa84398a0f0544c729c3221
• Mod/site from the demo video:
  • @pixies/test/timestamp-panel
  • https://store.google.com/US/?utm_source=hp_header&utm_medium=google_ooo&utm_campaign=GS100042&hl=en-US

Future Work

• For follow-up PR: review use of "showTemporarySidebarPanel", "updateTemporarySidebarPanel", "showSidebarForm". Should they ever be called from a frame? Or do the bricks need to run using target: top? We need to be careful not to break MV2 behavior expecations

Checklist

• Add jest or playwright tests and/or storybook stories
• Designate a primary reviewer: @fungairino

[fregante]

Yeah this change makes sense, the iframes should not interact with the sidebar at all. I think all of this logic should be moved as high up as possible, e.g. discard any sidebar extensions when in iframes; discard all sidebar-related messages or ensure that they're never sent to frames.

[twschiller]

discard any sidebar extensions when in iframes

The sidebar starter brick refuses to activate any mod components when running in a frame:

pixiebrix-extension/src/starterBricks/sidebarExtension.ts

Line 509 in 62355cf

return !isLoadedInIframe() && checkAvailable(this.definition.isAvailable);

But there are other calls that made their way to the controller: e.g.,

pixiebrix-extension/src/starterBricks/sidebarExtension.ts

Line 143 in 62355cf

clearModComponentInterfaceAndEvents(extensionIds: UUID[]): void {

As mentioned in Future Work, we need to review all the calls in the sidebarController to either ignore or throw an error. But we'll need to ensure we're not breaking backward compatibility for calls in MV2 (e.g., showing sidebar forms from frames)

[fungairino]

One thing I noticed is that the panels variable isn't synchronized in the SidebarController

pixiebrix-extension/src/contentScript/sidebarController.tsx

Line 126 in e1775b5

const panels: PanelEntry[] = [];

There's a comment on how the sidebarSlice handles race conditions here:

pixiebrix-extension/src/contentScript/sidebarController.tsx

Lines 201 to 202 in e1775b5

	// The sidebarSlice handles the race condition with the panels loading by keeping track of the latest pending
	// activatePanel request.

I'm a bit worried that we could run into this sort of buggy behavior again in the future so I'll spend some time in my spec slicing to investigate if there's any work here we could do to better prevent this sort of issue again.

[twschiller]

One thing I noticed is that the panels variable isn't synchronized in the SidebarController

What do you mean by not synchronized? Javascript is single-threaded

I'm a bit worried that we could run into this sort of buggy behavior again in the future so I'll spend some time in my spec slicing to investigate if there's any work here we could do to better prevent this sort of issue again.

@fungairino that comment is specifically referring to the case of using the Show Sidebar brick to try to show a specific panel in the sidebar. So there's a race as to if the "Show Sidebar" brick is called before that panel has been added to the sidebar

The comment is saying that the sidebarSlice handles the race condition, so the sidebarController doesn't have to handle the race condition

[fregante]

Will this also fix #8141? If the frames don't receive/handle the message, then we don't have to move the logic.

[fungairino]

What do you mean by not synchronized? Javascript is single-threaded

I'm thinking about improving the behavior if we have async calls that are removing all the panels and then updating them near the same time. Some way to more deterministically figure out the final state of panels given a series of aync calls to modify the panels, but maybe this is not exactly the right thing to worry about here.

[twschiller]

Some way to more deterministically figure out the final state of panels given a series of aync calls to modify the panels, but maybe this is not exactly the right thing to worry about here.

The sidebar currently handles that and the React app initialization race by enforcing message order. That logic has by and large been working well:

pixiebrix-extension/src/sidebar/protocol.tsx

Line 121 in 7908c96

function runListeners<Method extends keyof SidebarListener>(

[twschiller]

Will this also fix #8141? If the frames don't receive/handle the message, then we don't have to move the logic.

Not in its current state. We need to clarify the behavior of open sidebar, show sidepanel form, etc. from iframes. I would recommend we merge this PR in though and treat those in separate PRs

[fungairino]

The sidebar currently handles that and the React app initialization race by enforcing message order. That logic has by and large been working well: pixiebrix-extension/src/sidebar/protocol.tsx

TIL! Thanks for the context!

[fungairino]

I tested in MV2 as well and it looks like it works well!

[github-actions]

When the PR is merged, the first loom link found on this PR will be posted to #sprint-demo on Slack. Do not edit this comment manually.