Implement Resizable and growable ArrayBuffers
Categories
(Core :: JavaScript Engine, enhancement, P1)
Tracking
()
People
(Reporter: anba, Assigned: anba)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-complete)
Attachments
(36 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
Bug 1842773 - Part 10: Add {FixedLength,Resizable}DataViewObject classes. r=#spidermonkey-reviewers!
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
Bug 1842773 - Part 13: Remove TypedArrayObject::{length,byteLength}Value. r=#spidermonkey-reviewers!
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
The rendered proposal text has been pulled from https://tc39.es/proposal-resizablearraybuffer/. https://arai-a.github.io/ecma262-compare/?pr=3116 is currently the best option to see the changes.
Comment 1•2 years ago
|
||
Thanks for picking this up :)
Updated•2 years ago
|
| Assignee | ||
Comment 2•2 years ago
|
||
There's intentionally only a single shell option which controls both options.
This makes testing easier and the test262 tests are also using a single
feature flag for resizable ArrayBuffers and growable SharedArrayBuffers.
| Assignee | ||
Comment 3•2 years ago
|
||
Disallow resizable ArrayBuffers for:
- asm.js because it's not designed for resizable buffers.
- DOM bindings because
mozilla::dom::TypedArraycaches the TypedArrays's length. - Structured cloning because I haven't yet checked how structured cloning should
work when resizable ArrayBuffers are used.
Depends on D183317
| Assignee | ||
Comment 4•2 years ago
|
||
Change ArrayBufferObject into an abstract base class for the two new
classes FixedLengthArrayBufferObject and ResizableArrayBufferObject.
We need different classes, because resizable ArrayBuffers have slightly different
semantics and also need another reserved slot. Adding another reserved slot to
ArrayBufferObject changes the allocation kind from AllocKind::ARRAYBUFFER4
to AllocKind::ARRAYBUFFER8, which seems unfortunate for the common case of
non-resizable ArrayBuffers.
Depends on D183318
| Assignee | ||
Comment 5•2 years ago
|
||
Resizable ArrayBuffers need an additional reserved slot to store the maximum
byte length. Similar to ArrayBufferObject::BYTE_LENGTH_SLOT, this slot is set
to zero when the buffer is detached.
Depends on D183319
| Assignee | ||
Comment 6•2 years ago
|
||
Getters for maxByteLength or resizable simply read the corresponding slots.
Depends on D183320
| Assignee | ||
Comment 7•2 years ago
|
||
In preparation for actually enabling the ArrayBuffer constructor to create
resizable ArrayBuffers, we need additional functions to pass through the
correct JSClass and adjust the memory reporting to use the correct number of
associated bytes.
Depends on D183321
| Assignee | ||
Comment 8•2 years ago
|
||
Update the ArrayBuffer constructor function to create resizable ArrayBuffers.
DataViews and TypedArrays don't yet support resizable ArrayBuffers, so they
throw when a resizable ArrayBuffer is used as the input.
Depends on D183322
| Assignee | ||
Comment 9•2 years ago
|
||
Resizing simply adjusts the byte-length slot and sets the memory to
zero if the array is shrunk.
Depends on D183323
| Assignee | ||
Comment 10•2 years ago
|
||
Depends on D183324
| Assignee | ||
Comment 11•2 years ago
|
||
Similar to part 3, add separate classes for fixed-length and resizable
DataView objects.
Depends on D183325
| Assignee | ||
Comment 12•2 years ago
|
||
DataViews which are baked by a resizable ArrayBuffer can get out-of-bounds when
the ArrayBuffer is shrunk. It can later get again in-bounds when the ArrayBuffer
is grown. That means it's no longer possible to directly read the byte-length
and byte-offset from the reserved slots. Instead all accesses need to validate
the ArrayBufferView is still in-bounds. mozilla::Maybe is used to to represent
in-bound and out-of-bounds results.
Depends on D183326
| Assignee | ||
Comment 13•2 years ago
|
||
Depends on D183327
| Assignee | ||
Comment 14•2 years ago
|
||
Depends on D183328
| Assignee | ||
Comment 15•2 years ago
|
||
Similar to part 3, add separate classes for fixed-length and resizable
TypedArray objects.
Depends on D183329
| Assignee | ||
Comment 16•2 years ago
|
||
It's easy to add support for resizable typed arrays to branchIfClassIsNotTypedArray,
because the classes are in contiguous memory.
MacroAssembler::typedArrayElementSize is a bit more difficult, at least when
trying to avoid duplicating the detection for both fixed length and resizable
typed array classes.
Depends on D183330
| Assignee | ||
Comment 17•2 years ago
|
||
Replace TypedArrayObject with FixedLengthTypedArrayObject for part 18, when
TypedArrayObject::length() gets changed to handle out-of-bounds.
Depends on D183331
| Assignee | ||
Comment 18•2 years ago
|
||
Disabled until support gets added in a later patch in this stack.
Depends on D183332
| Assignee | ||
Comment 19•2 years ago
|
||
Update all accesses to handle possible out-of-bounds. In some cases the TypedArray
is guaranteed to be a FixedLengthTypedArrayObject, which ensures the accesses are
always in-bounds.
Depends on D183333
| Assignee | ||
Comment 20•2 years ago
|
||
Part 14 only disallowed attaching resizable typed arrays in CacheIR, but we
still need to guard the object is also a fixed-length typed array at runtime.
Depends on D183334
| Assignee | ||
Comment 21•2 years ago
|
||
Update the step comments and reload the TypedArray length before filling the
TypedArray per the resizable ArrayBuffer proposal.
Depends on D183335
| Assignee | ||
Comment 22•2 years ago
|
||
Throw a TypeError for out-of-bounds, but keep returning zero for detached buffers
to match the inlined JIT code.
Depends on D183336
| Assignee | ||
Comment 23•2 years ago
|
||
Simply calls PossiblyWrappedTypedArrayLength which throws an error for
out-of-bounds TypedArrays.
Depends on D183338
| Assignee | ||
Comment 24•2 years ago
|
||
Part 21 changed the TypedArrayLength to throw for out-of-bounds typed arrays,
but in a handful of cases we actually need to read the typed array length
without throwing an error for out-of-bounds.
Add a separate intrinsic for these cases and update the relevant self-hosted
functions to call TypedArrayLengthZeroOnOutOfBounds.
Depends on D183339
| Assignee | ||
Comment 25•2 years ago
|
||
Depends on D183340
| Assignee | ||
Comment 26•2 years ago
|
||
Depends on D183341
| Assignee | ||
Comment 27•2 years ago
|
||
The ArrayBuffer.prototype.slice update for resizable array buffers was
still missing.
Depends on D183342
| Assignee | ||
Comment 28•2 years ago
|
||
Depends on D183343
| Assignee | ||
Comment 29•2 years ago
|
||
Part 17 disabled Atomics for resizable buffers. Remove this restriction again.
Inlining Atomics functions for resizable buffers isn't affected by this change.
Depends on D183344
| Assignee | ||
Comment 30•2 years ago
|
||
Depends on D183345
| Assignee | ||
Comment 31•2 years ago
|
||
Depends on D183346
| Assignee | ||
Comment 32•2 years ago
|
||
Depends on D183347
| Assignee | ||
Comment 33•2 years ago
|
||
Depends on D183348
| Assignee | ||
Comment 34•2 years ago
|
||
Depends on D183349
| Assignee | ||
Comment 35•2 years ago
|
||
Depends on D183350
| Assignee | ||
Comment 36•2 years ago
|
||
Depends on D183351
| Assignee | ||
Comment 37•2 years ago
|
||
This is an initial implementation of the resizable ArrayBuffers proposal. The rendered spec is no longer available at https://tc39.es/proposal-resizablearraybuffer/, instead https://arai-a.github.io/ecma262-compare/?pr=3116 is probably right now the best option to view the changes. This is still missing SpiderMonkey-specific tests, but before starting to write tests I want to make sure the proposed implementation is actually acceptable.
Comment 38•2 years ago
|
||
(In reply to André Bargull [:anba] from comment #37)
This is an initial implementation of the resizable ArrayBuffers proposal. The rendered spec is no longer available at https://tc39.es/proposal-resizablearraybuffer/, instead https://arai-a.github.io/ecma262-compare/?pr=3116 is probably right now the best option to view the changes. This is still missing SpiderMonkey-specific tests, but before starting to write tests I want to make sure the proposed implementation is actually acceptable.
I left a bunch of comments on various phabricator revisions, which you probably won't see because it says it won't send out notifications for them since none of them are marked for review yet. I'm not actually sure how to see my comments without looking at each one in turn.
But to summarize, I think the approach is good. Most of my comments were in https://phabricator.services.mozilla.com/D183330. I'd like to hash out the C++ type hierarchy, because it's a mess before your patches and your patches multiply the stuff that's there.
Also, although I'm ok with allocating the max byte length up front, I'm worried about writing to the unused portion (for zeroing). It's pretty easy to imagine someone creating a whole bunch of max-1GB ABs with small initial sizes and then never resizing them, which would generate a lot of pressure (on the TLB, on paging space, etc.) It's certainly safer, but I'm worried that it won't fly. (It would also be nice to rely on demand-zeroed pages from the OS, but that's an optimization of much lesser concern.)
Comment 39•2 years ago
|
||
Sorry for the delay. These patches look good overall and the approach makes sense to me.
What's the situation for code outside of SpiderMonkey? Do we need to audit that or add support for resizable buffers?
| Assignee | ||
Comment 40•2 years ago
|
||
(In reply to Steve Fink [:sfink] [:s:] from comment #38)
I left a bunch of comments on various phabricator revisions, which you probably won't see because it says it won't send out notifications for them since none of them are marked for review yet. I'm not actually sure how to see my comments without looking at each one in turn.
Thanks! I'll go through the individual commits.
But to summarize, I think the approach is good. Most of my comments were in https://phabricator.services.mozilla.com/D183330. I'd like to hash out the C++ type hierarchy, because it's a mess before your patches and your patches multiply the stuff that's there.
I'll respond there.
Also, although I'm ok with allocating the max byte length up front, I'm worried about writing to the unused portion (for zeroing). It's pretty easy to imagine someone creating a whole bunch of max-1GB ABs with small initial sizes and then never resizing them, which would generate a lot of pressure (on the TLB, on paging space, etc.) It's certainly safer, but I'm worried that it won't fly. (It would also be nice to rely on demand-zeroed pages from the OS, but that's an optimization of much lesser concern.)
We use calloc when creating zeroed buffers, which should be fast when using system allocators (likely implemented using mmap(MAP_ANONYMOUS)), but I don't know if jemalloc's calloc uses the same kind of optimisations which are present in system allocators. If jemalloc's calloc touches every byte on the initial allocation, that's bad for the reasons outlined by you.
| Assignee | ||
Comment 41•2 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #39)
What's the situation for code outside of SpiderMonkey? Do we need to audit that or add support for resizable buffers?
The current patches are zeroing length (and byteOffset) output-parameters when an ArrayBufferView is out-of-bounds, so existing callers see them as zero-size views, which should be safe. If user-code can be executed to possibly resize the buffer between reading and using the length, existing code should (hopefully) already handle this case, because it's similar to detaching a buffer. mozilla::dom::TypedArray will require changes, so https://phabricator.services.mozilla.com/D183318 for now rejects creating mozilla::dom::TypedArray from resizable TypedArrays. That also means most DOM code won't currently work when resizable TypedArrays are used.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 42•1 year ago
|
||
Rename MaxByteLength to avoid confusion with the new maxByteLength slot for
resizable ArrayBuffers.
- Prefer "Limit" instead of "Max" because the latter could be misinterpreted to
refer tomaxByteLength, because it also includes the substring "max".
Depends on D183352
Comment 43•1 year ago
|
||
Comment 44•1 year ago
|
||
Backed out for causing build bustages in SharedArrayObject.cpp
- Backout link
- Push with failures
- Failure Log
- Failure line: /builds/worker/checkouts/gecko/js/src/vm/SharedArrayObject.cpp(306,13): error: unused function 'IsGrowableSharedArrayBuffer' [-Werror,-Wunused-function]
| Assignee | ||
Updated•1 year ago
|
Comment 45•1 year ago
|
||
Comment 46•1 year ago
•
|
||
Backed out for causing mochitest-plain failures on test_bug238987.html.
So far, this only affected Android 7.0.
-
Failure log
There are also this TV jobs that failed: -
https://treeherder.mozilla.org/logviewer?job_id=444702577&repo=autoland&lineNumber=4363
-
https://treeherder.mozilla.org/logviewer?job_id=444700903&repo=autoland&lineNumber=5173
[task 2024-01-26T09:02:48.489Z] 09:02:48 INFO - TEST-PASS | dom/events/test/test_bug238987.html | |window| should not have got a blur event, target [object HTMLDocument]
[task 2024-01-26T09:02:48.489Z] 09:02:48 INFO - Buffered messages finished
[task 2024-01-26T09:02:48.489Z] 09:02:48 WARNING - TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a blur event, target [object Window]
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - handleWindowBlur@dom/events/test/test_bug238987.html:90:7
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - EventListener.handleEvent*start@dom/events/test/test_bug238987.html:141:12
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.490Z] 09:02:48 WARNING - TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a blur event, target [object Window]
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - handleWindowBlur@dom/events/test/test_bug238987.html:90:7
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - EventListener.handleEvent*start@dom/events/test/test_bug238987.html:142:12
[task 2024-01-26T09:02:48.490Z] 09:02:48 INFO - Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - TEST-PASS | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object HTMLDocument]
[task 2024-01-26T09:02:48.491Z] 09:02:48 WARNING - TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object Window]
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - handleWindowFocus@dom/events/test/test_bug238987.html:63:7
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - EventListener.handleEvent*start@dom/events/test/test_bug238987.html:139:12
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.491Z] 09:02:48 INFO - EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.492Z] 09:02:48 WARNING - TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object Window]
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - handleWindowFocus@dom/events/test/test_bug238987.html:63:7
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - EventListener.handleEvent*start@dom/events/test/test_bug238987.html:140:12
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - Async*doTest@dom/events/test/test_bug238987.html:159:19
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - callStackHandler@SimpleTest/SimpleTest.js:285:24
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - EventHandlerNonNull*this.addLoadEvent@SimpleTest/SimpleTest.js:314:7
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - @SimpleTest/SimpleTest.js:1809:15
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - TEST-PASS | dom/events/test/test_bug238987.html | |window| should not have got a focus event, target [object HTMLInputElement], id="i2"
[task 2024-01-26T09:02:48.492Z] 09:02:48 INFO - TEST-PASS | dom/events/test/test_bug238987.html | Wrong activeElement!
[task 2024-01-26T09:02:48.493Z] 09:02:48 WARNING - TEST-UNEXPECTED-FAIL | dom/events/test/test_bug238987.html | (focus) Forward tabbing, expected [i3], got [i2]
[task 2024-01-26T09:02:48.493Z] 09:02:48 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:426:16
<...>
| Assignee | ||
Comment 47•1 year ago
|
||
(In reply to Iulian Moraru from comment #46)
Backed out for causing mochitest-plain failures on test_bug238987.html.
So far, this only affected Android 7.0.
These failures seem unrelated to this bug. Intermittent failures for "test_bug238987.html" were previously tracked in bug 1776983, so maybe there's a pre-existing issue with that test.
- Failure log
There are also this TV jobs that failed:
Thanks, this is indeed an issue with a test added in part 2. The test must only be run in debug-mode, because it uses debug-only features.
Comment 48•1 year ago
|
||
Comment 49•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/53fad2b43a0b
https://hg.mozilla.org/mozilla-central/rev/49226ab4093e
https://hg.mozilla.org/mozilla-central/rev/fe2a4caa1dd7
https://hg.mozilla.org/mozilla-central/rev/567f67b8e187
https://hg.mozilla.org/mozilla-central/rev/2b7cc2586ca5
https://hg.mozilla.org/mozilla-central/rev/cf831e50329b
https://hg.mozilla.org/mozilla-central/rev/a4808ad0653d
https://hg.mozilla.org/mozilla-central/rev/72fe72f79def
https://hg.mozilla.org/mozilla-central/rev/f4d118cc11eb
https://hg.mozilla.org/mozilla-central/rev/7fd46f4f4dc4
https://hg.mozilla.org/mozilla-central/rev/5568c4f7e127
https://hg.mozilla.org/mozilla-central/rev/2835f49b2bdc
https://hg.mozilla.org/mozilla-central/rev/c04808acc476
https://hg.mozilla.org/mozilla-central/rev/b82a9a84917f
https://hg.mozilla.org/mozilla-central/rev/f8f412e48ae6
https://hg.mozilla.org/mozilla-central/rev/40667536f69f
https://hg.mozilla.org/mozilla-central/rev/9978604b6be7
https://hg.mozilla.org/mozilla-central/rev/4118e5895c1c
https://hg.mozilla.org/mozilla-central/rev/457e09f19fcf
https://hg.mozilla.org/mozilla-central/rev/6ab8d493bddf
https://hg.mozilla.org/mozilla-central/rev/b2f91ee492ee
https://hg.mozilla.org/mozilla-central/rev/a3895c4f05b8
https://hg.mozilla.org/mozilla-central/rev/70abde51cfc3
https://hg.mozilla.org/mozilla-central/rev/6406d024f7e9
https://hg.mozilla.org/mozilla-central/rev/6df23bd678c0
https://hg.mozilla.org/mozilla-central/rev/ef37056db3f7
https://hg.mozilla.org/mozilla-central/rev/ac69b72d508b
https://hg.mozilla.org/mozilla-central/rev/616fce8c2915
https://hg.mozilla.org/mozilla-central/rev/ec958e11736a
https://hg.mozilla.org/mozilla-central/rev/bf7c93fe5eb7
https://hg.mozilla.org/mozilla-central/rev/28f978fb00cb
https://hg.mozilla.org/mozilla-central/rev/bcb108625dff
https://hg.mozilla.org/mozilla-central/rev/d01cb7f0d759
https://hg.mozilla.org/mozilla-central/rev/2bf38170c0e6
https://hg.mozilla.org/mozilla-central/rev/9049b720c9f9
https://hg.mozilla.org/mozilla-central/rev/fce9e7386189
Updated•1 year ago
|
Comment 50•1 year ago
|
||
FF124 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/32337
This is mostly just a compatibility data and MDN release note update.
Description
•