-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle closed tabs better while attempting to message them #3572
Conversation
const tabToOpener = new Map<TabId, TabId>(); | ||
const tabToTarget = new Map<TabId, TabId>(); | ||
// TODO: One tab could have multiple targets, but `tabToTarget` currenly only supports one at a time | ||
|
||
async function safelyRunBrick({ tabId }: { tabId: number }, request: RunBlock) { | ||
if (!(await canAccessTab(tabId))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this was being run first, it was reporting "no access" when the tab just didn't exist (was closed way too early).
Here you can see different error messages depending on how long I wait before closing the tab.
Screen.Recording.42.mov
const result = await Promise.race([ | ||
// If https://github.com/pixiebrix/webext-messenger/issues/67 is resolved, we don't need the listener | ||
onTabClose(tabId).then(() => TYPE_WAS_CLOSED), | ||
runBrick({ tabId }, request), | ||
]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there was a race condition (heh) right here. If onTabClose
resolved in time, we'd get "was closed". If not, we'd get the raw Chrome error because it would not be handled by this code at all.
You can see the two error message alternating here.
alternate.mov
Note
This alternating of message hasn't really been fixed by this PR.
Before
- BusinessError: PixieBrix doesn't have access to the tab
- BusinessError: The tab was closed
- Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received
After
- BusinessError: The target was closed before receiving a response
- BusinessError: The tab doesn't exist
Both are "tab doesn't exist" errors but sometimes we can track why it doesn't exist, so we can throw "tab was closed" instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this PR do?
This new behavior was fixed in the messenger itself:
Nit: unless we install a global tab tracker, it's hard to tell whether a tab ever existed.
Demo
target
Depending on how quickly the target is closed, the error will either be "tab doesn't exist" or "tab closed"
Screen.Recording.8.mov
Future Work
I should probably fix this permanently: