fix: prevent errors when extensions listen for chrome.tabs events

[codebytere]

Description of Change

Fixes two errors in Chrome extensions that are thrown when extensions listen for chrome.tabs. Initially, these weren't added to our tabs.json file as we didn't initially intend to support them. However, the way that extension generation works, omitting them from the JSON file actually means that attempting to listen to them at all will throw an error, which we don't want. We don't need to implement them or make them work as intended in order to define them as valid events to listen to here. No documentation or tests are changed as support has not changed as a result of this PR.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an error where listening to certain chrome.tabs events would throw incorrectly.

[deepak1556]

However, the way that extension generation works, omitting them from the JSON file actually means that attempting to listen to them at all will throw an error, which we don't want

Shouldn't the extensions avoid exercising these API when targeting Electron ? Maybe I am missing context, is the plan here for extensions to be able to run in Electron without any modifications, if that is the case what would be the error signal to extension authors when they use any undefined API ?

[codebytere]

@deepak1556 this cropped up initially because several of the main devtools extensions for web frameworks make use of these events (ex. onCreated and onUpdated), including React DevTools. I'm not sure I think it's reasonable for them by default to check whether the event is defined to prevent the entire extension from failing to run before using it given that the extensions are widely used, important for debugging, and Electron is the only context where they'd run into an issue.

They're not documented as being supported - would it perhaps help if we explicitly noted we did not support them? Prior to this PR we defined onZoomed even though we didn't actually support it for similar reasons (though I plan to potentially add support for this now that #39428 has landed).

[deepak1556]

Thanks for the context, do these extensions work fine when these tab events are declared but not implemented in Electron ? I see most of them as lifecycle related events, not sure if they cause any undefined behavior.

For me an error signal seems like the most explicit option for extensions, since Electron is not providing a 1:1 mapping of API from Chrome. However, would also love to hear thoughts from other maintainers on what they think is the best path.

[codebytere]

@deepak1556

do these extensions work fine when these tab events are declared but not implemented in Electron ? I see most of them as lifecycle related events, not sure if they cause any undefined behavior.

yes - before adding this i did a brief audit of the most commonly used devtools extensions and found that's how they were indeed used.

The thing about extension events generally that makes them tricky is we can't do what we've done for some unsupported functions and e.g. log a warning to console indicating it won't work as expected while allowing the extension to continue to function otherwise. That's what would imo be ideal here but the way extension generated functionality works forces our hand a bit here, and unfortunately these events not being implemented is a direct blocker to #36545

[deepak1556]

There is a "deprecated" property supported by the JSON compiler, can we use it to log error messages for the unsupported API and events ? Sample https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/extensions/api/tabs.json

[codebytere]

@deepak1556 oh great idea - i'll do that for now! done!

[release-clerk]

Release Notes Persisted

Fixed an error where listening to certain chrome.tabs events would throw incorrectly.

[trop]

I have automatically backported this PR to "25-x-y", please check out #39770

[trop]

I have automatically backported this PR to "27-x-y", please check out #39771

[trop]

I have automatically backported this PR to "26-x-y", please check out #39772