Proposal: limit length of extension action badge text

[bershanskiy]

Proposal

I propose to implement a simple check for the length of input to setBadgeText(). I believe the API should limit the number of bytes in the input string, not the character or render width, since those checks are more complex and depend on font rendering and particular style of UI which would differ between browsers.

Background

Extensions can set a custom badge (text) which is displayed over the extension action button in browser chrome. This UI element is very small and can display only a few characters or symbols or emojis, may be a few words written in Chinese or Korean. Despite clear visual limitations, setBadgeText() method accepts inputs of unbounded length.

1. Extensions can (accidentally) create long strings and consume the browser resources while all performance profilers would miss-attribute this memory usage to browser process.
2. Unlikely, but theoretically possible that extensions would use badge to store data. This may be convenient, since the actual storage APIs impose per-item limit and do not natively support keying storage by Tab ID and Window ID.

Considerations

1. Limit should be very permissive to enable extension developers' creativity.
2. Valid strings may contain multi-byte characters, including 4-byte emojis and emojis combined with 1-byte zero-width joiner (ZWJ). A single emoji rendered can be 19 bytes long if it combines four 4-byte emojis with ZWJ between them. Here is a concrete example of 19-byte string rendered by Chrome and Firefox as a single character. Only two such emojis fit in current Chrome UI for total length of 38 bytes.
3. Future or alternative browser UI revisions might be able to display more characters. Current Chrome UI can comfortably display only 4 digit numbers or 12 dots.

To ensure broad compatibility, we should introduce a histogram tracking the length of real-world badge strings.

Next actions

1. Please review histogram buckets in Chromium CL
2. Let's discuss this issue during meeting on 2026-03-12 (Agenda discussion for public meeting on 2026-03-12 #957)

External links

Chromium bug 491158086
Chromium CL for a histogram

[dotproto]

I'm supportive of improving badge text handling. That said, while I believe the issues described in the Background section are real, at the moment I don't think they're significant concerns in practice. I see this as an API polish issue and therefore relatively low priority.

I don't follow the suggestion that setBadgeText() should limit the input size based on the byte length of the string. My concern with using a fixed byte size is that as Unicode continues to evolve, we will end up rejecting valid strings that could be displayed in the allocated space. JavaScript uses UTF-16 as it's internal string encoding format, which is a variable-length encoding. To my knowledge, a single character can use up to 4 bytes per code point, but a single grapheme (a character as visible to a user) may be composed of multiple code points. Practically speaking, I don't think it's possible to know if a given input string will be renderable in the allocated space without parsing the string. Additionally, there a direct relationship between a grapheme's width and it's byte size.

logSize = (str) => console.log(`${new Blob([str]).size} bytes`);
logSize('Ỏ̷͖͈̞̩͎̻̫̫̜͉̠̫͕̭̭̫̫̹̗̹͈̼̠̖͍͚̥͈̮̼͕̠̤̯̻̥̬̗̼̳̤̳̬̪̹͚̞̼̠͕̼̠̦͚̫͔̯̹͉͉̘͎͕̼̣̝͙̱̟̹̩̟̳̦̭͉̮̖̭̣̣̞̙̗̜̺̭̻̥͚͙̝̦̲̱͉͖͉̰̦͎̫̣̼͎͍̠̮͓̹̹͉̤̰̗̙͕͇͔̱͕̭͈̳̗̭͔̘̖̺̮̜̠͖̘͓̳͕̟̠̱̫̤͓͔̘̰̲͙͍͇̙͎̣̼̗̖͙̯͉̠̟͈͍͕̪͓̝̩̦̖̹̼̠̘̮͚̟͉̺̜͍͓̯̳̱̻͕̣̳͉̻̭̭̱͍̪̩̭̺͕̺̼̥̪͖̦̟͎̻̰') // 427 bytes
logSize('👩🏼‍❤️‍💋‍👨🏼') // 35 bytes
logSize('﷽') // 3 bytes
logSize(' 𒐫') // 4 bytes

@bershanskiy, can you share more about your thinking behind choosing a fixed byte seize? I assume it was motivated at least in part by a desire to have a single value that could be implemented across browsers.

At the moment, I think it makes more sense for this method to accept an arbitrary length string, but for the browser to only retain the modified substring that is displayed in the badge itself. This would allow developers to continue providing arbitrary strings as they do today, retain the current string display behavior, limit the amount of memory browsers have to retain for the badge text, and address the use of this field as an arbitrary storage mechanism. The only risk that leaps to mind is that this could be a fingerprinting vector, but I'm not sure that's a practical concern as its trivial for an extension to retain a persistent installation ID using existing web or extension APIs.

[bershanskiy]

@dotproto Thanks for detailed comment.

To clarify: I agree that the display-ability of the badges which you mention is important. However, I believe we should consider rendering issues and accidental self-DoS separately. For self-DoS prevention, I merely propose a byte limit. The limit should be sufficiently large/permissive to continue enabling extension developers'' creativity. I was thinking

In this specific proposal I address the case of developer accidently passing long (e.g., multi-megabyte or multi-gigabyte strings) and browser not being to even store them in memory or slowing down significantly. This guardrail could be important for mobile browsers. A couple of major players appear to pursue or experiment with support feature-complete WebExtension API on mobile (Safari, Firefox, Chrome). I maintain that muli-gigabyte strings are not even worth an attempt to render or extract "the modified substring that is displayed in the badge". What do you think?

I don't think [issues in background section are] significant concerns in practice

These issues are rare on desktop browsers in popular officially released extensions. These issues may occasionally pop up during development, especially on resource-constrained mobile browsers. Or poorly programmed extensions in store with very few installs.

can you share more about your thinking behind choosing a fixed byte seize? I assume it was motivated at least in part by a desire to have a single value that could be implemented across browsers.

Yes, I would like to make these limits universal, if possible. I would like to have a simple if-else clause for detecting the most obvious faults as early as possible to incur minimal runtime processing cost and browser developer/maintainer time.

At the moment, I think it makes more sense for this method to accept an arbitrary length string,

"Arbitrary length strings" is a very vague definition. Strings may be very long in practice. In theory, ECMAScript specification only requires strings to be no longer than Number.MAX_SAFE_INTEGER, which would be over 16TiB. According to MDN, on 64-bit systems (all modern computers and phones) popular modern browsers support gigabytes worth of strings (Chrome ~1GiB, Firefox ~2GiB, Safari ~4GiB). In practice, badges this long either would be cut off in UI or the same glyphs would have a more concise (shot) and practical expression.

but for the browser to only retain the modified substring that is displayed in the badge itself.

It's non-trivial to extract a sub-string of a string which would have the same rendition. The closest equivalent in DOM, Intersection Observer API is apparently not capable of tracking text visibility and instead tracks the HTML element containing the text. The browser chrome is even less capable (probably, mostly for performance and security reasons).

A more practical optimization would be to render the badge text, then crop the parts definitely not visible to the user (purely based on the visible pixel box). May be, then the browser could discard the original text, but that would not be compatible with getBadgeText().

Thanks for bringing up a few concrete examples.

Unicode Diacritic marks

logSize('Ỏ̷͖͈̞̩͎̻̫̫̜͉̠̫͕̭̭̫̫̹̗̹͈̼̠̖͍͚̥͈̮̼͕̠̤̯̻̥̬̗̼̳̤̳̬̪̹͚̞̼̠͕̼̠̦͚̫͔̯̹͉͉̘͎͕̼̣̝͙̱̟̹̩̟̳̦̭͉̮̖̭̣̣̞̙̗̜̺̭̻̥͚͙̝̦̲̱͉͖͉̰̦͎̫̣̼͎͍̠̮͓̹̹͉̤̰̗̙͕͇͔̱͕̭͈̳̗̭͔̘̖̺̮̜̠͖̘͓̳͕̟̠̱̫̤͓͔̘̰̲͙͍͇̙͎̣̼̗̖͙̯͉̠̟͈͍͕̪͓̝̩̦̖̹̼̠̘̮͚̟͉̺̜͍͓̯̳̱̻͕̣̳͉̻̭̭̱͍̪̩̭̺͕̺̼̥̪͖̦̟͎̻̰') // 427 bytes

Diacritic marks are important in some languages and scripts. However, more commonly online people creatively abuse this system for meme potential. Sometimes this kind of text is called "cursed", "hacked", or "glitched" because of its uncanny appearance. I'm not sure whether any real extensions would actually attempt to use it in production, especially to the extent demonstrated here.

Longer Unicode strings with Emojis and ZWJ

logSize('👩🏼‍❤️‍💋‍👨🏼') // 35 bytes

This is significantly longer than 19-byte sequence I proposed above. I wonder what is the technical limit for an Emoji?

Short byte sequences rendered into large graphical symbols

logSize('﷽') // 3 bytes
logSize(' 𒐫') // 4 bytes

Thanks for these examples. My proposal does not impact these cases.

[dotproto]

I maintain that muli-gigabyte strings are not even worth an attempt to render or extract "the modified substring that is displayed in the badge". What do you think?

AFIAK once an extension creates a huge string the expensive part (memory allocation) is done. When the extension calls action.setBadgeText() and passes the string to the WebExtensions layer, the implementation will receive a reference to that string and can work against it in the same process "for free". We only have to worry about paying additional costs when IPC gets involved. As such, whatever validation or modification of the input text we want to perform should happen in the extension process.

Browser engineering folks, please correct me if I got anything wrong here.

"Arbitrary length strings" is a very vague definition.

Sorry about the vague language, but it seems you got my intended meaning: a JavaScript string. What I was trying to get at is that we can't control the size of the string when the extension creates it, since that's a language-level concern rather than a platform level one. We can only control how the WebExtension API handles that input.

It's non-trivial to extract a sub-string of a string which would have the same rendition. Intersection Observer API is apparently not capable of tracking text visibility and instead tracks the HTML element containing the text.

My first thought here is that DOM likely can't do this because of other challenges related to the box model, intrinsic sizing, computationally expensive property evaluation, opacity, etc. That said, I'll readily admit that I may have underestimated the complexity of my suggestion.

Do you have any links for other discussions related to sub-string extraction? I imagine that special purpose characters could make it difficult to determine where a visible string starts and ends.

A more practical optimization would be to render the badge text, then crop the parts definitely not visible to the user (purely based on the visible pixel box). May be, then the browser could discard the original text, but that would not be compatible with getBadgeText().

I'm not sure if this is true in all browsers, but I think badge text rendering is handled by the browser process rather than the extension process. In that case, we can't work render the string or we'll run into (a version of) the same problem we're trying to avoid in the first place.

I think a breaking change is unavoidable. If setBadgeText() throws, that changes the function signature. If it silently setBadgeText() changes input text, the return value returned by getBadgeText() will be different. In either case, existing extension code may no longer behave as expected.

Diacritic marks are important in some languages and scripts. … I'm not sure whether any real extensions would actually attempt to use it in production, especially to the extent demonstrated here.

I included this specific example mostly because it was a concrete case where a single rendered character was significantly larger than I would have guess it could be. Based on my brief exploration yesterday, it looks like "real" Unicode text (as in, not "cursed" or emojis) max out at 4 bytes per grapheme. But of course unusual things will happen in the wild and the platform should handle them in a reasonable way.

A practical scenario where I can imagine this being a material concern is if an extension allowed its users to set custom badge text for different extension states via the extension's options page. I wouldn't expect users to know or care how the strings they copy-paste are handled under the hood.

I wonder what is the technical limit for an Emoji?

I looked for but didn't find one. One of the resources I consulted was this (salvis.com) blog post, which details how 👩🏼‍❤️‍💋‍👨🏼 is constructed. That post concludes with the following note:

Theoretically, a grapheme can be built by an unlimited number of characters. As far as I know, 10 characters and 35 bytes for the kiss emoji 👩🏼‍❤️‍💋‍👨🏼 with two persons and a skin tone modifier are currently the maximum. This makes sizing [an Oracle database] column with emojis a bit challenging.

Thanks for these examples. My proposal does not impact these cases.

I included these because they were relevant for the width-based approach I was suggesting. They were also nice illustrations of how a single grapheme cluster could fit within a narrow byte window but far exceed a visual limits.

[bershanskiy]

Let's make sure we don't miss the forest for the trees: I do not suggest to reduce the length of badges used in practice, just to add an if-then statement for returning early on clearly buggy strings. I propose to define some very large (permissive) limit that would be multiple times larger than what could feasibly fit in browser UI now and in the future. For example, 500 or 1000 bytes or even more. Just anything less than megabytes of data.

I appreciate the compatibility problem here: if API throws an error, it might break the extension; if API silently ignores overly long (invalid) input (or merely logs a developer warning), user might see it as being broken; if API attempts to be "clever" and modifies the string in any way, this modification becomes a magical behavior which looks like a bug.

I think we should avoid attempts to find an exact byte count of a longest codepoint sequence fitting into the UI. The exact byte count would likely depend on the Unicode revision, browser we choose, possibly the platform (OS, hardware properties like screen resolution, etc.) and future changes to these.

I made an error in the initial comment: the string 👨🏼‍👩🏼‍👧🏼‍👦🏼 is actually 41 bytes long. (Please see below.)

AFIAK once an extension creates a huge string the expensive part (memory allocation) is done.

Any data has to live somewhere. My main concern is high resource usage on memory-constrained (especially mobile) devices.

Off-topic: Memory allocation is not inherently "expensive". Memory allocation patterns might be inefficient, but they are not more expensive than any other memory access (for the most part). Sometimes user-space programs don't have enough unused memory on-hand and have to make a system call, sometimes they have enough reserve of free memory requested by earlier system call but not currently used. The second case typically takes longer, but not by much. The bigger problems might arise from memory "fragmentation" both in virtual memory space and on actual hardware. Since we are talking about a single string here, I don' think fragmentation (of either kind) would be a problem.

A practical scenario where I can imagine this being a material concern is if an extension allowed its users to set custom badge text for different extension states via the extension's options page. I wouldn't expect users to know or care how the strings they copy-paste are handled under the hood.

In this scenario I would prefer overly long byte arrays to be rejected at some point. If extension does not have a simple check ensuring the input is reasonable, then the browser definitely should have one.

One of the resources I consulted was this (salvis.com) blog post, which details how 👩🏼‍❤️‍💋‍👨🏼 is constructed.

the kiss emoji 👩🏼‍❤️‍💋‍👨🏼 with two persons and a skin tone modifier

The 41-byte example I provided was supported back in Windows 10 Anniversary Update released in August of 2016. (source) The blog post is dated 2024-09-30, a while later, so I'm not sure regarding its credibility.

Both my example and the one from blog are constructed very similarly:

1. Emojis can have modifiers inserted after them. Both examples use a person emoji (4 bytes) with a color modifier (4 bytes). The resulting grapheme is 8 bytes long.
2. Some emojis can be combined into a single grapheme by inserting a zero-width joiner (ZWJ) between them. ZWJ is 3 bytes long. Combined grapheme has length equal to sum of lengths of both emojis and ZWJ.