Idea: AbortSignal argument of functions that may cause arbitrary delay

[Max Nikulin]

Am I the only person who misses ability to cancel a call to extensions
API if it is not completed in reasonable time or till another user action?

Before filing a feature request I have decided to ask if it will be
useful for others.

Some API methods may take enough time till completion because user
interaction or web page JavaScript are involved. Examples:
- permissions.request
- scripting.executeScript
- offscreen.createDocument

I think, an AbortSignal parameter similar to fetch() may be handy to
cancel execution when result is not necessary any more or when some
action should be prevented if it is too late.

I have tried a wrapper around executeScript to set deadline, but bult-in
support of AbortSignal should be a more reliable option.

Have I missed an already existing solution?

[Oliver Dunk]

Hey Max,

I also think this would be really cool! There are some specific ways of doing this in certain APIs - for example, chrome.desktopCapture has a cancelChooseDesktopMedia function. But you're right that there isn't a way to do this more universally right now.

If you can't find a bug, please do open one!

One of the tricky things here would be that it's unclear where it would go in different APIs. An extra parameter you can pass? A property you set somewhere? Definitely solvable, but would require some thinking.

I usually use Promise.race with two promises, the one I actually care about and then one that will just reject after a set period of time. That usually seems like a fairly nice solution.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1a2f7bdc-ce22-735a-2df6-bf3377930f0d%40gmail.com.

[Max Nikulin]

On 28/06/2023 22:22, 'Oliver Dunk' via Chromium Extensions wrote:
>
> There are some specific ways of
> doing this in certain APIs - for example, chrome.desktopCapture has a
> cancelChooseDesktopMedia

> <https://developer.chrome.com/docs/extensions/reference/desktopCapture/#method-cancelChooseDesktopMedia>
> function.

Thank you, Oliver for this example. I have never used the desktopCapture
API. At first glance, with help of AbortSignal, the
cancelChooseDesktopMedia method and desktopMediaRequestId can be made
unnecessary. A method that should be introduced in addition to
chooseDesktopMedia may return a Promise for a {streamId, options}
object. Method's last argument may be either a callback or a {callback,
signal} object with optional fields. Another variant is an additional
"parameters" ({signal}} argument before callback.

An example of current API that does not require any change is messaging
using connections. Ports can be closed when necessary. Unfortunately
such technique would be inconvenient for functions returning single value.

> If you can't find a bug, please do open one!

Do you mean a Chromium bug or https://github.com/w3c/webextensions/ ? My
impression is that the latter one is better for discussion.

> One of the tricky things here would be that it's unclear where it would
> go in different APIs. An extra parameter you can pass? A property you
> set somewhere? Definitely solvable, but would require some thinking.

Polymorphic functions increase complexity of implementation code, but
{callback, signal} may be a viable alternative to just callback function
as the last argument.

> I usually use Promise.race with two promises, the one I actually care
> about and then one that will just reject after a set period of time.
> That usually seems like a fairly nice solution.

To deal with current API, Promise.race or callback wrappers are
unavoidable. Besides timeout, another reason to not wait results is a
new action initiated by the user, so processing of the previous action
should be abandoned. A kind of execution context object is necessary
anyway to observe cancellation. Approximately the same amount of code is
required to implement such context purely with promises or to use
AbortController and AbortSignal pair and convert the signal into a
promise when necessary. A minor advantage of second approach is that the
signal may be reused for fetch() directly without an adapter converting
promise to a signal instance.

A bit more tricky task is to pass deadline to a content script to not
run it at all if delay between calling scripting.executeScript and
actual execution is too large. I have even tried killing content script
by another call of executeScript, but I consider it fragile. Native
support of scripts aborting may keep developers aside from such complexity.

[Oliver Dunk]

I think the WECG would definitely be a good place for this. It feels like we'd need to change the APIs in ways which would affect all browsers.

Polymorphic functions increase complexity of implementation code, but {callback, signal} may be a viable alternative to just callback function as the last argument.

As an object you mean? The tricky thing with that would be that it would break existing extensions - but we should avoid chatting here and wait until we bring this up in the community group :) 

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/bcdb7cac-f26f-c491-c7a2-e7b10bd43f2b%40gmail.com.

[wOxxOm]

Currently there's an ongoing work to enable "strong keepalive" for a number of API that can take more than 5 minute to resolve, see https://crbug.com/1418780

[Max Nikulin]

On 30/06/2023 21:27, wOxxOm wrote:
> Currently there's an ongoing work to enable "strong keepalive" for a
> number of API that can take more than 5 minute to resolve,
> see https://crbug.com/1418780

The goal of my proposal is the opposite: allow to *cancel*
permissions.request, scripting.executeScript, etc. when e.g. another
user action happens (action, contextMenus, commands). It may happen
while the service worker is active.

[Max Nikulin]

On 30/06/2023 16:48, 'Oliver Dunk' via Chromium Extensions wrote:
> but we should avoid chatting here and wait until we bring this up in the
> community group :)

https://github.com/w3c/webextensions/issues/415
Allow to cancel method calls

[Oliver Dunk]

Thanks for this!

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/4fa3fde0-97fc-0e5b-82bb-e17d43b19869%40gmail.com.