Event Filtering by criteria other than URL

[EricLaw-MSFT]

When adding a listener for various events (e.g. webNavigation.onCommitted), it's possible to supply an filter that prevents the event from being dispatched if it doesn't meet the filter criteria. This can improve performance by avoiding the overhead of dispatching events not of interest to the extension.

Are there any types of filters available other than UrlFilter? In particular, it would be very useful to have a TabFilter that enables filtering events based on the tab to which the event belongs.

By way of example, consider the Chrome team's "Suspicious Site Reporter" extension, which aims to swap the Browser Action's icon shown in Chrome's toolbar based on the top-level URL loaded in the tab. The extension has a background page which monitors chrome.tabs.onActivated and chrome.tabs.onUpdated to ensure that as the user switches tabs or navigates, the icon properly reflects data from the current page.

The problem is that chrome.tabs.onUpdated fires constantly for every tab in the browser, even those that aren't active. The current code:

    chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {

      if (tab.active && (changeInfo.url || changeInfo.status)) {

        setBrowserActionAndIcon(tab);

      }

    });

...checks if the tab is active, and if it's not, it bails out immediately. The problem is that by doing this bailout in the background page (instead of as a filter), the background page must first be activated, and that is especially expensive for this extension, which fetches parses hundreds of kilobytes of JSON.

If addListener filtering could support other types of filters, to wit:

    chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {

        setBrowserActionAndIcon(tab);

    }, {tab: {active:true}, changes: {["url", "status"]}} );

...the filtering step could be moved out and Chrome could avoid waking the background page for events we don't care about.

Is there some other way to achieve this today? 

[wOxxOm]

No, not with chrome.tabs API as it doesn't have such a filter, but onUpdated usually can be replaced with several chrome.webNavigation event listeners as they support url filters. As for onActivated, there's no direct analog but in case you have a content script on all URLs you can probably use Page Lifecycle API events in it.

BTW almost the exact feature you're looking for is implemented in Firefox where a lot of interesting and useful features get added in their WebExtensions API variant. Whereas in Chrome the public extensions API is basically frozen. For the last five years there was no noteworthy development (at least from Chromium developers) except for DeclarativeNetRequest API, almost everything they did was bug fixing, refactoring, and other small-time maintenance. There's like a hundred of good ideas submitted on crbug.com that are shelved/ignored for the lack of "bandwidth" as they say nowadays. And the fun part is that those ideas were ignored in the ManifestV3 draft. Makes one wonder...

[Eric Lawrence]

> No, not with chrome.tabs API as it doesn't have such a filter, but onUpdated usually can be replaced with several chrome.webNavigation event listeners as they support url filters. 

Right. The explicit problem is that URLFilters are not fit for purpose. We need to filter not on the URL, but on the related tab's active state.

> almost the exact feature you're looking for is implemented in Firefox

Thanks! Firefox's extraParameters filter is indeed almost what I'm looking for, but they'd need to add a tabIsActive filter to meet the need identified in this thread.

[Simeon Vincent]

I just dug up an issue for filters on chrome.tabs http://crbug.com/254929. IMO this definitely sounds like a gap we should fill.

There's like a hundred of good ideas submitted on crbug.com that are shelved/ignored for the lack of "bandwidth" as they say nowadays. 

I don't want to derail the thread too much, but anything in particular you'd like to call out? 

[wOxxOm]

Personally I'd like to see Promise-based API being implemented as part of ManifestV3 instead of the really awkward and unwieldy callback-based API we always had, see crbug.com/328932. Implementing it via window.browser seems like a no-brainer to me especially since it already works in Chrome almost flawlessly with the help of Mozilla's WebExtension polyfill. That would be one change in ManifestV3 that's not about punishing and restricting the extensions but rather evolving to keep with the times.

[Simeon Vincent]

Promise-based APIs are on the way. I believe the current plan is to have APIs that currently return undefined instead return a promise where appropriate rather than expose them on a separate namespace.

This is a bit of a pipe dream, but TBH I wish the web platform had streams/observables so we could have more ergonomic APIs for cases that currently require callbacks. Maybe some day…

Simeon - @dotproto

Extensions Developer Advocate

[wOxxOm]

I'm reaaaaaly not so sure about that. It could get easily postponed to ManifestV4 as there's quite a few big changes already in ManifestV3 that require a lot of effort to implement. Moreover the general mood of the MV3 draft and further announcements was about tightening security and restricting extensions. I'd love to be mistaken but so far we haven't seen an official announcement about all those feature requests and bug reports that are being stalled for months or even years.

[Simeon Vincent]

Yesterday I talked to the tech lead about this and confirmed we're planning to implement promise APIs as part of the MV3.

AFAIK Chromium doesn't really do announcements about backlog status. Honestly I can't think of a project that does. That said, I'm happy to try to look into specific issues.

Simeon - @dotproto

Extensions Developer Advocate

[wOxxOm]

On Wednesday, August 7, 2019 at 7:22:56 PM UTC+3, Simeon Vincent wrote:

Yesterday I talked to the tech lead about this and confirmed we're planning to implement promise APIs as part of the MV3.

Nice. Fingers crossed.

 

AFAIK Chromium doesn't really do announcements about backlog status. Honestly I can't think of a project that does. That said, I'm happy to try to look into specific issues. 

When a project has a long history of ignoring/shelving feature requests and bug reports in one particular area (extensions API) a moment will come when someone has to face the facts and fix it. Maybe change the "bandwidth" allocation or whatever that was preventing the situation from resolving for something like five years. The first step should be of course acknowledging the problem, and even that didn't occur yet, apparently.