Running brick in broadcast mode takes 4+ seconds

[twschiller]

Steps to Reproduce

• Have 6 tabs open, 3 of which have PixieBrix active
• Create a flow like the following
• Click the button
• The confetti takes 4+ seconds to appear

The RUN_BRICK subcall for each tab is attempting 11 times:

Investigation

• Should only be getting called on tabs PixieBrix thinks is ready: http://github.com/pixiebrix/pixiebrix-extension/blob/3b15b511dee8d67510a9f642f598de8df236210f/src/background/executor.ts#L143-L143 (edited)

[fregante]

The RUN_BRICK subcall for each tab is attempting 11 times:

That shouldn't affect the time it takes because those targets just don't exist. I'm not sure how it worked before, but probably a similar behavior existed but was silent.

Retrying is done:

• to wait until the content script is ready
• to wait until a named target is created and becomes ready

I think currently this retry time is around 4-5s. We can reduce the noise by limiting the broadcast to tabs we actually have access to rather than "all tabs".

[fregante]

• Should only be getting called on tabs PixieBrix thinks is ready:

That may be already happening, but I think that array isn't updated? So visiting a permitted host and then navigating away, still leaves the "tab ready" mark in that array if I remember correctly.

[twschiller]

That may be already happening, but I think that array isn't updated? So visiting a permitted host and then navigating away, still leaves the "tab ready" mark in that array if I remember correctly.

Correct, we aren't removing tabs from tabReady on 1) full navigation, 2) closing the tab. So the tabReady just accumulates a bunch of stale information we then try to message

The good news is that the retry time is constant (or relatively constant) w.r.t. number of outdated tabs

I wonder it it’s better to try to maintain tabReady or just ping the tabs once prior to broadcast? Or somehow turn off retry in the messaging library?

[twschiller]

I confirmed that the delay is also present in 1.4.10, so I won't hold up the 1.4.11 release for this

[fregante]

Interesting! So that excludes #2090

I opened a few relates tickets, but I don’t think they're directly related to this problem. #2193 would reduce noise and potentially allow me to drop a lot of "tab ready" code, so it's worth doing soon anyway.

[fregante]

I'm not seeing a huge delay in execution, maybe less than half a second. The only issue is that it does take 4.3 seconds for the action to complete since the background handler still has to wait for the retries to end before responding. This is the log in the origin tab:

broadcast.mov

I'll fix:

• Limit broadcasting to tabs with permissions (replaces tabReady object) #2193