Incorrect "connection lost" message for multi-page flows

[twschiller]

Steps to reproduce

• Create an extension with a 1) open tab, 2) wait (window: target)
• Run the extension and close the new target tab while it's waiting

Actual Behavior

• On the starting tab, PixieBrix will show a non-dismissable connection lost alert

Expected Behavior

• PixieBrix should show a normal action failed message for the action. (It still has a connection to the host page)

Considerations

• We should record a more informative error message in this case, such as "Target tab unexpectedly closed"
• This also affects opener target. If the opener tab is closed, it should be "Opener tab no longer exists", and/or "Opener tab unexpectedly closed

Related code:

• The BackgroundLogger error method shows a notification. The error text must be transformed before it hits that http://github.com/pixiebrix/pixiebrix-extension/blob/F/bug/avoid-double-reporting/src/telemetry/BackgroundLogger.ts#L80-L80

[fregante]

This might be a little involved because with the Messenger we've basically gone towards: "Try messaging this target, until it exists, full stop."

The Messenger doesn't differentiate between a non-existing target and a target that's loading, we tried to make it completely opaque to the caller. Other requirements that came along, like named targets ("tabId-less targets"), also changed how we wait for this to happen and what we allow as an "error" that allows retries.

I'll look into it tomorrow, maybe it's unrelated to all that.

[fregante]

Uh oh. It's actually a deeper problem. We can't distinguish between:

• the page unloaded before responding (tab closed or page refreshed)
• the tab never existed

Here's what happens:

1. The tab receives the message and the sender awaits a response
2. You close the tab
3. Chrome throws "The message port closed before a response was received."
4. webextension-polyfill purposefully silences this error, resolving the underlying sendMessage with undefined:
   • Closing the receiver tab will not throw an error in tabs.sendMessage() mozilla/webextension-polyfill#365
5. webext-messenger treats undefined as a loading error or "the extension has not yet loaded" 🟣
   • Use cleaner Messenger + ignore non-handled messages #1753
   • https://github.com/pixiebrix/webext-messenger/blob/192b35b10c599f38b16c22ae747bf60360d06771/source/sender.ts#L73-L76)
6. webext-messenger will retry
7. The tab no longer exists, so we start getting "Could not establish connection. Receiving end does not exist."
8. The time runs out
9. webext-messenger throws this last error
10. The extension treats this error as a complete runtime failure 🟣

The steps marked with 🟣 can likely be improved with little effort. I don't expect the polyfill to fix this issue in the short term or maybe even ever.

[fregante]

I opened 3 issues to document this behavior:

• Closing the receiver tab will not throw an error in tabs.sendMessage() mozilla/webextension-polyfill#365
• Documentation: How sendMessage responds webext-messenger#66
• If a tab is closed before the method responds, the Messenger throws "Could not establish connection" webext-messenger#67

[twschiller]

I think your analysis looks correct. I was thinking of just solving the proximate cause:

Can we just wrap the runBrick calls in a try/catch and change the error message? This should be a BusinessError, since when dealing with target/opener/etc. it's generally a misconfigured multipage extension

• requestRunInTarget
• requestRunInOpener

Then our handlers that look for connection related errors would just see it as a normal error