Proposal: Limits on lengths of strings passed to WebExtension APIs

[bershanskiy]

Most WebExtension APIs hang when they receive overly long strings. In a typical page, when JS calls a Web-exposed API, at worst it can hang a singe web frame or a tab. Extensions run with less isolation and in practice can hang the entire browser. This is a blanket issue where I'll index all WebExtension APIs and manifest fields and current browser behavior.

API Analysis

Action Title

String sources

• action.setTitle() (user-visible, dynamic)
• action.default_title manifest key (user-visible, static, localizable)
• browser_action.default_title manifest key (user-visible, static, localizable)

Alarm Name #422

String sources

• alarms.create({name}) - (non-user-visible, dynamic)
  • Alarm name length limit - No length limits in any browser, every browser can hang.
  • Alarm count limit
    • Chromium 117 (PSA, commit) limits each extension to 500 alarms, throwing an error 'An extension cannot have more than 500 active alarms.' if extension attempts to create 501-th alarm.
    • Firefox does not have a limit, tracking bug
• alarms.clear(name)
• alarms.get(name)

Next Action

Collect data from Chrome 144 Histogram, discuss during meeting on Jan 29, 2026.

Paths in extensions

Extension icon path length

• action.setIcon({path})

Extension popup path length

• action.setPopup({popup})
• browser_action.setPopup({popup})

Extension badge text #960

• action.setBadgeText({text})

Chrome issue: https://issues.chromium.org/issues/491158086
Chrome Histogram CL: https://chromium-review.googlesource.com/c/chromium/src/+/7651914

Process to introduce string length limit

Tentative steps to introduce a limit for an API:

1. Identify parameter which does not have a limit yet. Fill out Column 1.
   For example, "alarm name".
2. Identify every API method and/or manifest key where this parameter may occur as an input (source of long inputs for browser). Fill out Column 2.
   For example, for "alarm name", sources can be alarms.create({name}) alarms.clear(name) alarms.get(name). While some other APIs also deal with alarm names (e.g., alarm.getAll() would still be overloaded by long alarm names), they are actually outputs (sinks of long names).
3. Figure out current behavior in browsers.
   Try to pass long inputs for each method and/or manifest key identified in step 2 and record outcome. Repeat with a few browsers, if technically possible and time allows.
4. Introduce a study (a histogram) to track usage in one browser.
   Identify appropriate "buckets" of input lengths. Preferably, list them in the table above and/or dedicated issue under WECG repository. Also, discuss potential future behaviors for dealing with long inputs (silently ignore, ignore with a warning, or throw an error).
5. Wait for study results
   Wait a few "milestones" for histogram code to reach stable releases, then a few more to collect reasonably representative data.
6. Finalize the proper limit and behavior for long inputs.
   Discuss study results in WECG tracker or a meeting.
7. Add WPT cases for he limit and implement the new behavior in at least one browser.

[oliverdunk]

@bershanskiy recently added a histogram to Chromium to track alarm name length: https://source.chromium.org/chromium/chromium/src/+/main:extensions/browser/api/alarms/alarm_manager.cc;l=175;drc=42b022b36244f99067ec9a6aabbcb00d28c7beaf

This has been in stable since Chrome 144 so we have a reasonable amount of data now. We are limited around what we can share from this data however I can summarize it as follows:

• Most alarm names (> 99.8%) are 100 characters or shorter.
• There is an interesting spike accounting for about 0.2% of alarm names in the 501 <= N <= 1000 bucket.
• Alarm names longer than 1000 characters account for less than 0.003% of the data.

We had discussed an initial limit of 1024 characters in a previous meeting which we might then bring down in the future. That definitely seems reasonable to me, as it accounts for more than 99.99% of alarm names including the spike at the top end of the limit.

[bershanskiy]

@oliverdunk Thank you for the comment. If you have time, here are two things perhaps worth considering before meeting on Wednesday.

1. If possible, could you please check if the statistics changed in the last four weeks?
   During meeting on 2026-01-15, Rob for the first raised the concern about the data accuracy given the shortness of the data collection interval. During meeting on 2026-01-29, we discussed the data you posted above. Perhaps, if we have up-to-date data on 2026-02-26, we could make the final decision about the limit.
2. Can we agree on the wording of the console warning for calls to alarms.create()?
   Does Chrome need a specific deprecation milestone? If so, do we have everything to pick the milestone and commit to it? I have no strong opinions, but I would prefer to have some king of fixed timeline, even a very far in advance. The mere existence of the warning in the console should motivate developers to move data to storage.local.
3. If we commit to a milestone, polyfil libraries could augment alarms.create to store data in storage.local and also extend alarms.onAlarm handlers to retrieve this data and pass to developers' alarm handlers.
4. I expect yet unreleased Android Desktop to benefit the most from this limit. Should we apply the limit on Android Desktop (even before official release) without this limit being considered a breaking change?

[oliverdunk]

If possible, could you please check if the statistics changed in the last four weeks?

It looks like the 1001 <= N <= 2000 bucket has increased slightly (now at about 0.02% on Windows). However, the data looks otherwise the same.

Can we agree on the wording of the console warning for calls to alarms.create()?

Happy to discuss, but I'm not sure if this is something we need to align on.

Does Chrome need a specific deprecation milestone? If so, do we have everything to pick the milestone and commit to it?

We don't have concrete guidance on this but I would suggest we add a warning for a few milestones. We could perhaps make this a hard error by Chrome 149 which branches at the start of May (or Chrome 148 in April if we really want to move quickly).

I expect yet unreleased Android Desktop to benefit the most from this limit. Should we apply the limit on Android Desktop (even before official release) without this limit being considered a breaking change?

Let's discuss that on the CL.

[oliverdunk]

@Rob--W @xeenon Are you comfortable with 1024 as the new limit for alarm names? It would be great to align on that async so we can land the change in Chromium.