docs: add alarms.clearAll() return value Safari exception

[carlosjeurissen]

Fixes #45149

Description

This PR adds the return type Safari exception to the return type section.

Motivation

To help developers handle edge cases.

Additional details

Return type discussion in WECG:
w3c/webextensions#1055

Related issues and pull requests

Fixes #45149

@kiaraarose @xeenon FYI

[github-actions]

Preview URLs (1 page)

• /en-US/docs/Mozilla/Add-ons/WebExtensions/API/alarms/clearAll

(comment last updated: 2026-09-03 04:02:44)

[rebloor]

@carlosjeurissen my reading is that both Chrome and Safari have active patches in their release process to align browser behavior. Could you add details of those so the reader is aware that the situation may change (and, based on the timing of any updates on MDN, they have already changed by the time they read the documentation.)

[bershanskiy]

Safari (WebKit) already merged and plans to release the change aligning with Firefox (returning true if at least one alarm was cleared and false if extension had no alarms).
Chrome always returns true but Chrome team currently considers whether they want to align with Firefox and future Safari or propose yet another behavior. WECG meeting agenda has this topic scheduled for today's meeting.

[bershanskiy]

Safari Technology Preview 251 released yesterday (August 26) shipped the new behavior (consistent with Firefox).

[bershanskiy]

During WECG meeting on August 27, 2026, browsers agreed to change the return type of alarms.clearAll() from a Promise<Boolean> to Promise<undefined>.

Safari plans to revert the move from Promise<undefined> to Promise<Boolean> and restore its original behavior.

• Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2067229
• WECG bug (linked earlier): Inconsistency: Return value for alarms.clearAll() w3c/webextensions#1055

[rebloor]

@carlosjeurissen please could you update the note to align with the decision and current status.

[bershanskiy]

I'm not sure whether we should update MDN content yet, given the lack of even a single implementation using Promise<undefined>. This borders on developer outreach regarding future plans rather than factual documentation of existing extension platform. From my side, I promise to notify MDN once I and a Chromium CL migrating from Promise<true> to Promise<undefined>.

[bershanskiy]

I created Chromium CL 8182627 migrating alarms.clearAll() return value from Promise<true> to Promise<undefined>. The change has a runtime switch to revert to original behavior in case of compatibility issues. Most likely, this change will be merged in time for Google Chrome 155 release. After CL is merged, I expect Chromium devs to publish a PSA on Chromium Extensions mailing list and I will try to post a link here once that occurs. Anyone interested is welcome to follow that CL and bug linked in the CL description.

[rebloor]

Thanks @carlosjeurissen. As things seem a little fluid, it may be worth waiting for them to settle down. Let me know when you have the final, settled change.

[carlosjeurissen]

@rebloor updated the PR to mention future changes to undefined and the recommendation to not rely on the return type. We can always follow up with a new PR once browsers have landed the change to undefined and the release versions are known.

[rebloor]

Thanks @carlosjeurissen

[bershanskiy]

I promised to post a message here once Chromium implements the new behavior. Chromium has merged the change and is on track to ship it in Chrome 157. I created #45951 to update MDN content and mdn/browser-compat-data#30716 to update BCD.