Split Wasm mutable globals into specific features by chrisdavidmills · Pull Request #29503 · mdn/browser-compat-data

chrisdavidmills · 2026-04-17T11:53:45Z

Summary

As part of my mission to document all the missing Wasm features, I am working on making sure Wasm mutable globals are properly documented. We previously had a webassembly.mutable-globals data point, but this was just describing the overall feature itself, rather than the specific parts of the tech that comprise the feature. And it was only used to show a BCD table on the WebAssembly main landing page — having this many BCD tables on the same page is not a great user experience, so I have decided to start removing them and showing the information elsewhere.

I have updated the BCD to get rid of that, and:

Add a specific subfeature for the mutable option of the WebAssembly.Global() constructor.
Add separate data points for the global, global.get, and global.set Wasm text format instructions. I've put these in an instructions directory, and I could also see us adding further directories for definitions, types, etc.

This is not ready to merge yet. The main outstanding issues are as follows, which I am hoping @eqrion and colleagues can weigh in here and advise, as well as the BCD folks:

I have no idea if the browser support versions are correct. For now, I've just copied the mutable_globals support versions. I'm not really sure how to find all this information (for Wasm instructions in general, not just these few instructions) without it being hugely time-consuming. Any thoughts?
We need to get agreement on whether this kind of structure is appropriate and will work for Wasm?

Test results and supporting details

Related issues

github-actions · 2026-04-17T11:54:36Z

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

eqrion

Wasm 1.0 shipped in Firefox 55, Chrome 57, and Safari 11. You can use those version numbers for any instruction/definition that wasn't in a wasm proposal.

I also double checked the versions for the mutable globals proposal.

[1] https://www.firefox.com/en-US/firefox/52.0/releasenotes/?redirect_source=mozilla-org
[2] https://chromestatus.com/feature/5453022515691520
[3] https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_0.html

eqrion · 2026-04-20T20:17:43Z

For wasm proposals, feature status is where browsers announce their support for a proposal.

eqrion · 2026-04-20T20:19:15Z

We need to get agreement on whether this kind of structure is appropriate and will work for Wasm?

I don't know much about how browser compat data works. The data in this PR seems reasonable, but also probably very repetitive? It'd be nice to automate or simplify it so it doesn't need to be per-function or per-definition.

Co-authored-by: Ryan Hunt <rhunt@eqrion.net>

chrisdavidmills · 2026-04-21T09:47:55Z

The linter is currently failing because it doesn't recognise https://webassembly.github.io/spec/core/ as a valid spec. I've requested it be added in w3c/browser-specs#2449.

chrisdavidmills · 2026-04-21T09:50:36Z

For wasm proposals, feature status is where browsers announce their support for a proposal.

Ah ha, this is really useful.

chrisdavidmills · 2026-04-21T10:00:39Z

We need to get agreement on whether this kind of structure is appropriate and will work for Wasm?

I don't know much about how browser compat data works. The data in this PR seems reasonable, but also probably very repetitive? It'd be nice to automate or simplify it so it doesn't need to be per-function or per-definition.

Generally, what we do is record browser compat data as granularly as possible. This has many advantages in terms of flexibility:

You can refer to individual features, or group them to provide an overall sentiment of support for an entire spec or API, which is what we do with the baseline project
If a bug is found with a particular feature, or a new option (or whatever) is introduced, we can easily add that.
Generally, it is rare that an entire spec or featureset will have exactly the same browser support, so we need to be able to expose those differences.

So yes, it is pretty repetitive, but we can use a script to generate lots of BCD support files pretty quickly, provided the support data is the same. This is what I'm intending to do for the SIMD stuff I've just added. I'm assuming all the fixed-width SIMD instructions were supported at the same time (in the versions referred to on https://webassembly.org/features/?categories=browsers)?

chrisdavidmills · 2026-04-22T09:32:11Z

The linter is currently failing because it doesn't recognise https://webassembly.github.io/spec/core/ as a valid spec. I've requested it be added in w3c/browser-specs#2449.

OK, scratch that. The bikeshed version of the spec is already in the system, so I'm using that instead. It is more searchable than the other version anyway.

eqrion · 2026-04-22T14:33:44Z

So yes, it is pretty repetitive, but we can use a script to generate lots of BCD support files pretty quickly, provided the support data is the same. This is what I'm intending to do for the SIMD stuff I've just added. I'm assuming all the fixed-width SIMD instructions were supported at the same time (in the versions referred to on https://webassembly.org/features/?categories=browsers)?

Yes, all the fixed-width SIMD stuff was added in the same version. AFAIK, every wasm proposal has shipped as a unit in the same release. There may be some odd exceptions for a bug like you say, but I'd assume by default everything shipped together.

caugner · 2026-04-30T20:22:27Z

@chrisdavidmills I was loosely following the conversation and was under the impression that this PR is not yet ready for review, but I might be wrong. Are you able to confirm?

chrisdavidmills · 2026-05-01T07:32:55Z

@chrisdavidmills I was loosely following the conversation and was under the impression that this PR is not yet ready for review, but I might be wrong. Are you able to confirm?

@caugner yes, this is ready for review now.

This may require a bit more back and forth than the average review, as I am proposing a new data structure for Wasm features, so that we can have per-instruction/type/definition/whatever BCD rather than the really high-level ones that we had previously. Obviously, it would be good to get your input on the proposed structure.

I'm also thinking that, for BCD on the main WebAssembly landing page, it would be good to link to https://webassembly.org/features/?categories=browsers rather than showing a million different compatibility tables, which is pretty messy.

caugner · 2026-05-07T16:41:06Z

I would opt to merge webassembly.instructions.global_{get,set} into webassembly/instructions.json. No need for per-feature JSON files.

@caugner, there are hundreds of instructions overall, especially when you start to consider the Wasm SIMD instructions. I can see how the single file would lead to a neater repo, but wouldn't it become a bit unwieldy?

If more instructions will be added, then this indeed makes sense.

Add more accurate/specific BCd for Wasm mutable globals

e26d6a3

chrisdavidmills marked this pull request as draft April 17, 2026 11:53

github-actions Bot added the data:wasm Compatibility data for WebAssembly features. https://developer.mozilla.org/docs/WebAssembly label Apr 17, 2026

chrisdavidmills requested a review from caugner April 17, 2026 11:54

github-actions Bot added the size:l Pull request changing 101-1,000 lines of code. label Apr 17, 2026

Add instructions object level

ecb3f11

eqrion reviewed Apr 20, 2026

View reviewed changes

Comment thread webassembly/instructions/global.json Outdated

Comment thread webassembly/instructions/global.json Outdated

chrisdavidmills and others added 3 commits April 21, 2026 10:32

Merge branch 'main' into wasm-mutable-globals

2e3cf08

Update webassembly/instructions/global.json

b351eee

Co-authored-by: Ryan Hunt <rhunt@eqrion.net>

Update webassembly/instructions/global.json

7bb6486

Co-authored-by: Ryan Hunt <rhunt@eqrion.net>

chrisdavidmills added 2 commits April 21, 2026 11:02

Move global to definitions directory

c7922e6

update spec URLs to bikeshed version

19729a6

chrisdavidmills marked this pull request as ready for review April 22, 2026 09:32

Merge branch 'main' into wasm-mutable-globals

1cbb421

Merge branch 'main' into wasm-mutable-globals

d8e3c69

caugner requested changes May 7, 2026

View reviewed changes

chrisdavidmills added 2 commits May 11, 2026 09:57

Merge branch 'main' into wasm-mutable-globals

c2b4989

apply auto fixes

abb7864

caugner approved these changes May 15, 2026

View reviewed changes

caugner changed the title ~~Add more accurate/specific BCD for Wasm mutable globals~~ Split Wasm mutable globals into specific features May 15, 2026

caugner merged commit f14ff99 into mdn:main May 15, 2026
9 checks passed

mdn-bot mentioned this pull request May 15, 2026

Release v7.3.16 #29640

Merged

Conversation

chrisdavidmills commented Apr 17, 2026

Summary

Test results and supporting details

Related issues

Uh oh!

github-actions Bot commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eqrion left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

eqrion commented Apr 20, 2026

Uh oh!

eqrion commented Apr 20, 2026

Uh oh!

chrisdavidmills commented Apr 21, 2026

Uh oh!

chrisdavidmills commented Apr 21, 2026

Uh oh!

chrisdavidmills commented Apr 21, 2026

Uh oh!

chrisdavidmills commented Apr 22, 2026

Uh oh!

eqrion commented Apr 22, 2026

Uh oh!

caugner commented Apr 30, 2026

Uh oh!

chrisdavidmills commented May 1, 2026

Uh oh!

caugner May 7, 2026

Choose a reason for hiding this comment

Uh oh!

chrisdavidmills May 11, 2026

Choose a reason for hiding this comment

Uh oh!

caugner May 15, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions Bot commented Apr 17, 2026 •

edited

Loading