Unexpected error -- alarms.create: Delay is less than minimum of 5 minutes.

[RichardS]

I am converting an extension to use event pages and have replaced setTimeout() with chrome.alarms.create() as recommended.

The extension runs fine when I am loading it as an unpacked extension in development. When I package the extension as a .crx and load it through dragging to the Extensions page (Installed by a third party) the background page console reports errors:

  Error during alarms.create: Delay is less than minimum of 5 minutes.  (sendRequest:22)

Is there a minimum delay requirement for packaged extensions ? If so, can it be made shorter ?

I am running Chrome Version 24.0.1312.40 beta-m on 64-bit Windows 7 Professional.

The extension manifest looks ok for alarms:

  "permissions": [

    "tabs", "http://*/*", "https://*/*",

    "contextMenus",

    "alarms"

  ],

[Jeffrey Yasskin]

On Tue, Dec 18, 2012 at 3:40 AM, RichardS <rsop...@gmail.com> wrote:
> I am converting an extension to use event pages and have replaced
> setTimeout() with chrome.alarms.create() as recommended.
>
> The extension runs fine when I am loading it as an unpacked extension in
> development. When I package the extension as a .crx and load it through
> dragging to the Extensions page (Installed by a third party) the background
> page console reports errors:
>
> Error during alarms.create: Delay is less than minimum of 5 minutes.
> (sendRequest:22)
>
> Is there a minimum delay requirement for packaged extensions ? If so, can it
> be made shorter ?

Yes, we enforce a minimum delay of 5 minutes, mostly because the
implementation won't call you any more often than that anyway: See
https://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/extensions/api/alarms/alarms_api.cc&l=75,
https://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/extensions/api/alarms/alarms_api.cc&l=113,
and https://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/extensions/api/alarms/alarm_manager.cc&l=351
(and sorry for the inadequate comments). The delay is shorter in
development to help you debug, but it's enforced when you release.

We're trying to make sure extensions don't wake up users' computers
too often because that sort of polling hurts battery life. Can you
register a callback of some sort instead of polling?

> I am running Chrome Version 24.0.1312.40 beta-m on 64-bit Windows 7
> Professional.
>
> The extension manifest looks ok for alarms:
>
> "permissions": [
> "tabs", "http://*/*", "https://*/*",
> "contextMenus",
> "alarms"
> ],

Thanks for the supporting details.

[RichardS]

Hi Jeffry,

Thanks for the feedback.This should at least be documented as we didn't spot it during development.

The issue we have is that the alarm is being used an an internal event timeout. So routinely, we create the alarm (period 1 minute) when we initiate the event and cancel it when the event completes successfully - usually within a couple of seconds (before event pages we where using setTimeout for this purpose). If it does timeout then this is an error condition which we need to handle.

While the extension is running in this mode we do not expect it to unload as it remains "busy". At other times our extension is in an "idle" mode and we would like and expect it to unload (the benefit of event pages).

Given that developers can choose not to implement event pages at all then your argument for keeping the duration long makes no sense. It should be up to developers to code the most system friendly extension they can based on the facts. One solution we have it to not implement event pages at all and go back to the persistent approach. 

thanks

richard

[Jeffrey Yasskin]

On Thu, Dec 20, 2012 at 9:13 AM, RichardS <rsop...@gmail.com> wrote:
> Hi Jeffry,
>
> Thanks for the feedback.This should at least be documented as we didn't spot
> it during development.

It's now documented on
trunk—http://developer.chrome.com/trunk/extensions/alarms.html—and
that'll make its way to the stable documentation during the normal
release process. Thanks for the nudge. :)

> The issue we have is that the alarm is being used an an internal event
> timeout. So routinely, we create the alarm (period 1 minute) when we
> initiate the event and cancel it when the event completes successfully -
> usually within a couple of seconds (before event pages we where using
> setTimeout for this purpose). If it does timeout then this is an error
> condition which we need to handle.
>
> While the extension is running in this mode we do not expect it to unload as
> it remains "busy". At other times our extension is in an "idle" mode and we
> would like and expect it to unload (the benefit of event pages).

Yeah, I'm not sure the best way to handle error timeouts with event
pages. You could accept the ~5-minute minimum from chrome.alarms,
possibly augmenting that with a setTimeout call to improve the latency
in case your page doesn't get unloaded. That's not ideal because it's
more complicated for you. Can you describe in a little more detail
what errors might cause this timeout? We probably won't make any
changes around this in the near future, but I'll keep your use case in
mind in case a good fix presents itself.

Jeffrey

[Richard Soppelsa]

Hi Jeffrey,

To describe our use case: We have an extension that automates the browser and runs over many days but with long periods of being idle. The time-outs are used to monitor events, such as a page loads, for failure. Event pages are of interest to us because we have found we leak memory over extended periods. The unloading of the extension during idle periods releases memory and greatly improves performance.

Our default time-out period is currently one minute so we will probably increase this to 5 and specify this is a minimum to fit in with the current event design. Also, I will have a think about the hybrid time-out approach you suggested.

thanks

richard

[Jeffrey Yasskin]

Thanks for the details.