Extension sidebar load time/reliability

[twschiller]

Steps to reproduce

• In a development build
• Add actions/context-panel panel extension via the Workshop. For reproducing, you can just attach a Markdown brick for the body
• Go to a web site
• Click the PixieBrix toolbar icon opens the sidebar

Expected behavior

• The PixieBrix side bar opens in < 1s

Actual behavior

• The side bar layouts can take what seems like 2-3 seconds to load in some cases. (This is particularly true on pages that PixieBrix does not have permanent access to, so that when the user clicks the toolbar, the content script is being loaded to the page for the first time)
• Some percentage of the time, the panel that is attached to the sidebar gets stuck in a loading state (with the grid loader showing)

Discussion

• Some of this is probably related to a broader discussion of reducing the initial load times of the entry points. I suspect the bottleneck/root cause is messaging, but bundle size could also be a contributing factor

[twschiller]

I just tried to reproduce the problem using the release build and didn't have a problem (loading is fast, and the panel always loads properly): https://github.com/pixiebrix/pixiebrix-extension/actions/runs/916635393

I think it's still worth looking into this issue though as having it get stuck in a loading state is annoying during development

[fregante]

I tried loading chrome-extension://mpjjildhmpddojocokjkgmlkkkfjnepo/action.html in a new tab to exclude any delays with the injection.

I think this is most of all a "huge bundle" issue. On my fast computer I get the DOM ready event at 1.3s and the load event at 1.5s. That's a lot for an offline application but it likely has to do with double-digit uncompressed bundle it has to load.

In the production build I'm already seeing a more reasonable 400ms and 470ms respectively. This page totals 4.8MB.

[twschiller]

@fregante I'm closing this issue because it works in the production build and also seems to be working better in development with the recent webpack/dependency changes.

Will re-open as necessary

[fregante]

I thought of a possible improvement: Don't inject the whole content script just to add the iframe.

Is this doable? Is the content script used for anything else other than the injection in this case?

My idea would be to inject a tiny file which is probably something along the lines of:

const sidebar = select(…)
if (sidebar) {
	sidebar.remove();
	document.documentElement.marginLeft -= SIDEBAR_WIDTH_PX;
} else {
	document.body.insertAdjacentHTML('beforeEnd', '<iframe id="pixiebrix-frame" etc>')
	document.documentElement.marginLeft += SIDEBAR_WIDTH_PX;
}

This would definitely speed up injecting as the browser does not need to evaluate the whole content script + wait for communication just to open the sidebar.

It would also completely avoid this issue since the background page would have "direct" access over the page (by calling executeScript('toggleSidebar.js')):

• Sidebar occasionally fails to be injected #963