Only delay/wait for managed storage once on browser extension startup

[twschiller]

Context

• Discussion: https://pixiebrix.slack.com/archives/C023KL47XV4/p1709336975134639
• We have a delay to ensure we read managed storage:

  pixiebrix-extension/src/store/enterprise/managedStorage.ts

  Line 35 in 22bc0cc

  const MAX_MANAGED_STORAGE_WAIT_MILLIS = 4500;

• However, we incur that delay in all contexts using managed storage if storage is not set (i.e., for non-enterprise users)
• We should be setting a marker/flag once we've determined the managed storage state for the browser session so that we don't incur page load delays
• Triaging: moving to backlog b/c this would impact many screen performance for non-enterprise users

Considerations

• Be careful on events for MV2/MV3 based on background worker recycling. Does onStartup fire only on the profile startup? Or on worker recycling? https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onStartup

Potential Implementation Approaches

• On MV3, we could use the shared in-memory storage to set a flag saying that managed storage has been initialized / we’ve determined that it’s not set. That session storage gets reset automatically on profile startup
• On MV2, we could have the context ping the background page for that information. That would be higher latency. There might be a way to track that in localStorage too — the background page on startup could:
  • Clear a chrome.local storage key
  • Wait for managed storage to be initialized
  • Set a chrome.local storage key indicating managed storage has been initialized/is unset
  • Calls to

    pixiebrix-extension/src/store/enterprise/managedStorage.ts

    Line 149 in 22bc0cc

    export const initManagedStorage = once(async () => {

    could check the flag/listen for changes to the flag to abort waiting the 4.5 seconds

[fungairino]

An example of a place where this latency is impacting the app:

pixiebrix-extension/src/telemetry/performance.ts

Line 51 in c50ddca

const baseUrl = await getBaseURL();

Because it takes 4.5 seconds to check for the service url, the datadog rum library isnt initialized fast enough to cover the initial API calls to the service.

[fregante]

What's in the managed storage? Can it always just be initialized later? i.e. just open the defaults/localStorage first and then update them once the managed storage is received, via hook if it affects a react app.

I don't know the ratio of users on/off managed storage, but this negatively affects users who are not on it (1s-4s if managed; full 4.5s if not managed)

[twschiller]

What's in the managed storage? Can it always just be initialized later?

See keys here:

pixiebrix-extension/static/managedStorageSchema.json

Line 4 in 22bc0cc

"managedOrganizationId": {

Unfortunately, we need managed storage because it's used to enforce branding and restrictions. I think the adjustment described in the implementation approaches will solve most of the problem. There will still be a 4.5s delay on initial startup, but that's generally not noticeable anyway because: 1) on install from CWS, it's unclear when the download finished vs. when the extension starts up, 2) on fresh browser profile startup there's generally other tabs/extensions popping up

The long-term solution will be: w3c/webextensions#547