Allow external runtime messages so that other extensions can interface with the suspender

[dt-rush]

I have a use-case where I have an extension which helps my efficiency at work. I'd like to have my extension listen on certain pages and suspend them as soon as they open, so I can spawn the tabs without taking up much memory.

I want to have the content script send a message to the runtime when it's on a page which matches, however the issue is that currently, the background.js uses the following pattern:

//HANDLERS FOR MESSAGE REQUESTS

chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) {
    if (debug) {
        console.log('listener fired:', request.action);
        console.dir(sender);
    }

    switch (request.action) {
    case 'prefs':
        sendResponse({

...etc.

By extracting that function and simply doing both

chrome.runtime.onMessage.addListener

and

chrome.runtime.onMessageExternal.addListener

This would enable the extension to receive events from other extensions which want to use the suspend functionality in a more specific manner.

[dt-rush]

Reference in chrome.runtime docs:

https://developer.chrome.com/extensions/runtime#event-onMessageExternal

https://developer.chrome.com/extensions/runtime#event-onMessage

[Dan Atkinson]

Given that this seems like very specific use case for you, it might be best to for the extension and make your own changes.

Alternately, you could commit a pull request with the changes you made.

[dt-rush]

Hi Dan,

Thanks for your reply. I think it would be a very broadly-applicable change to make, since it allows any other extension to make use of the suspend tab functionality by exposing the API. Thanks for the awesome work of making this extension, as it's saved me lots of system-resource-contention headaches in an environment where I open many tabs but don't need to work on all of them right away.

I'll submit a pull request with the simple change necessary, and hopefully it's clear and simple enough to warrant a commit :)

[Dan Atkinson]

I don't make the extension, just merely contribute. :)

[dt-rush]

:3 fair enough, thanks for your contributions!

[Dean Oemcke]

It looks like the external message api has been pretty badly broken for a while. This has just been remedied in the above commit and there is now a new api. It has two endpoints which must be called as follows:

{ action: 'suspend', tabId: 123456789 }
{ action: 'unsuspend', tabId: 123456789 }

where tabId must be an integer, but is optional. if it is omitted, the action will default to the currently focused tab.

the call will return a null response on success, or an error string if the call failed.

[dt-rush]

I have ceased to work at the company that initially wanted me to develop an extension making use of this feature, hahaha! I ended up - at the time - using some kind of hack where I used window.open() with a URL in the pattern that the great suspender uses to symbolize a suspended tab (of course, that was an unstable API compared to this, so good to see it implemented!)

[Aditya]

Hi @deanoemcke

Do you have a release date planned for this update?

I have an update in my extension (ClutterFree) that will use this feature to communicate with TGS, and wanted to time it based on your release schedule.

Cheers!

Adi

[Dean Oemcke]

@adityabhaskar afaik the current dev build is bug free :touchwood:
im going to put it through some regression testing this week and hoping for a full rollout by the end of the month.
that said, it's not the first time i've attempted this :(