Reconsider top-level await status regression

[ddbeck]

Summary

The top-level await feature (dist) may regress from Baseline widely available ("Baseline high") to not Baseline (aka limited availability), due to a bug in Safari. This has been temporarily blocked with an editorial override.

This issue is meant to determine if we're to follow the compat data or maintain an editorial override, allowing the feature to remain Baseline high.

Background

In Safari, simultaneous imports of a module with a top-level await fails with a ReferenceError. This bug has been present since September 2021, when Safari first shipped top-level await (this is also the feature's keystone release).

However, the bug was not reported until later. In July 2022 (about 10 months after top-level await shipped), the bug's first public report to WebKit was filed (webkit bug 242740).

In July 2023, this issue was reported by developers to BCD.

In December 2024, we first published the top-level await feature (#2417), using data that did not reflect the Safari bug.

On April 29, 2025, BCD updated the data and marked Safari's support as partially implemented.

On May 2, 2025 the update landed in web-features. I withheld a release, pending discussion on the issue. In May 8, 2025's WebDX call, we decided to apply an override while we discuss the issue further, judging that a full regression from Baseline high to non-Baseline merited a closer review. I applied that (temporary) fix in #2954.

Since Februrary 2024, a PR to fix this bug in WebKit has been open (WebKit/WebKit#24122), though it's incomplete and unmerged. WebKit maintainers have commented on it, saying that there's work needed, but not scheduled, to fix this bug.

Owner's group questions

This status must be resolved by the web-features owners group. If we cannot reach consensus, then we may put it to a vote of the owner's group to resolve. The main questions follow:

• Should we let the (temporary) editorial override stand?

  That is, do we believe that the bug is a "showstopper" that should cause developers to think twice before using top-level await across browsers? Or do we think this is a minor bug that is not generally relevant to the Baseline audience?

• Should we unlink the compat key from the top-level await feature?

  Consumers may use a generated per-key status. In this case, this feature has a single key. Should we unpublish the per-key status for this key? Presently, we do not have a facility for overriding a per-key status (see Override individual BCD keys #1690).

Related links

• Webkit bug 242740 – [JSC] ReferenceError when multiple modules are simultaneously importing a module containing a top-level await
• [JSC] ReferenceError when multiple modules are simultaneously importing a module containing a top-level await WebKit/WebKit#24122
• javascript.operators.await - Top level await isn't properly supported in Safari mdn/browser-compat-data#20426
• javascript.operators.await - Add a note of partial top-level support in Safari mdn/browser-compat-data#26075
• Safari only partially supports top-level await mdn/browser-compat-data#26510
• Comment on BCD bump with regression #2921
• Reversion of preceding regression
• Baseline status regressions should require a note #1971

[ddbeck]

Before I filed this issue, there was some discussion about this in the WebDX Matrix chat. I'm reproducing some highlights here:

@jgraham asked about developer impact:

Practically do we have evidence of people avoiding top-level await in general because of this bug?

I responded, noting a few ways that web developers signaled that this matters:

• This problem had multiple reports against BCD from developers, suggesting that the data was misleading.
• The webkit bug (and unmerged pull request to fix it) seemed to have an unusual number of comments (I don't have any numbers to back this up, but it seemed like an above-average number to me).
• […] a Svelte maintainer call[ed] it "a very serious Safari bug".

James continued, noting that the bug-to-BCD timeline seemed possibly too long to qualify this bug as serious enough to regress the status and risks around creating bad incentives with a precedent:

It just a-priori feels unlikely that it's both so significant a bug that it means the feature has to be avoided entirely, but also it took >2½ years to be marked in the BCD data.

Of course it's not impossible. Maybe baseline is giving BCD data more visibility. But I think there's a real risk here that authors start to use BCD annotations, and therefore baseline status, as a way to pressure vendors to fix low-impact bugs that they personally find annoying.

He also suggested feature-splitting as an alternative:

In general I'd much prefer feature-splitting in cases like this where something has reached actual-baseline (not just "newly available") vs downgrading the entire feature. But that's hard to do when it's a bug that affects specific uses of the feature vs just specific parts of the feature.

@captainbrosset suggested that the trigger for the bug is perhaps too rare but difficult to feature split:

The bug does feel serious, but the conditions to encounter it seem rare.
[…]
At the same time, I don't see a logical way to split the feature here other than by doing "top level await" and "top level await with this one bug fixed".
Unlike other cases where we've managed to split, there doesn't seem to be a sub-feature we can define here.

[ddbeck]

For my part—after going back and forth on after the discussion on chat and the WebDX call—I think we should follow BCD, allow the regression, and preserve the key mapping in web-features. My main case in favor of this route is two-pronged:

• The combination of WebKit bug comments, WebKit PR comments, and BCD issues and comments suggests many developers are bothered by this bug. I think BCD was justified in marking the feature as partially implemented in Safari, as opposed to only linking to a relevant bug.
• In the absence of a known defect in BCD or a limitation of its data model, we ought to avoid overrides in the name of maintainability and predictability.

[jgraham]

FWIW I think my concerns about BCD "partial implementation" statuses being used as advocacy tools are mostly mitigated by a process where:

• We never automatically regress features from "baseline high" status, but always require a manual decision.
• That decision requires consensus (or something close to it)

That is, I think the bar for regressing baseline status should be very high, and we should instead have processes to ensure that features that are shipping but have significant interop challenges are identified as early as possible in the "newly available" state, so that we can plan a way to address those challenges.

In particular I think we should have active monitoring and triage of BCD issues filed on keys relating to features in the "newly available" state. One of the values of the 30 month timeline for something to reach the "widely available" state is that it provides us with this window of opportunity to find these issues. Ideally any problems significant enough to warrant regressing the status are identified within 3 months of the feature reaching newly-available. Anything found after 24 months (and especially after 30 months) should be considered possible evidence of process failure on our part.

Of course, in this case we weren't doing any of that in the 30 month window, and indeed the web-feature didn't exist for most of that time. So it's less surprising that we'd run into issues.

Personally, in terms of assessing the severity of the bug, I'd also like input from the WebKit developers, as they may have the best understanding of how severe a problem it's causing for users of WebKit-based browsers.