Patch to report JS GC things that are live at shutdown as leaks by calling MOZ_LOG_CTOR for them. The JS engine now clears any remaining roots to prevent dangling pointers to freed memory after shutdown. I made XPCJSRuntime::Shutdown keep the weak pointer update callbacks as sometimes these tables have entries remaining at shutdown (if there are leaks) and we need the callbacks to update them.
This is looking more green on try now.
Differential Revision: https://phabricator.services.mozilla.com/D40449
--HG--
extra : moz-landing-system : lando
When browsing reported site (https://minecraft.curseforge.com/), user that uses Android cannot set caret on some editable contents.
GV's IME code uses `NOTIFY_IME_OF_SELECTION_CHANGE` to update selection on native IME. But GV doesn't receives this notification on this reported site. This notification is fired by editor's selection listener, but when this occurs, this notification is no logner fired unfortunately. Because selection listener isn't registered by current selection.
At first, editor registers selection listener by `EditorBase::Init`. But like test case, if PresShell is destroyed after editor is created, this registration is no longer used, and we have to register it by new selection again. So we should tear down editor when PresShell is destroyed. (or we have to add a way to re-initialize selection listener?)
This isn't related to Android. Android's IME code depends on this notification, so this occurs easily.
Also, `PresShell::SetCaretEnabled` only works when caret is valid (`PresShell::GetCaret` has caret). If caret is nothing, it hits assertion.
And, attached test case is reproduced sample.
Differential Revision: https://phabricator.services.mozilla.com/D41356
--HG--
extra : moz-landing-system : lando
- Throw a TypeError when a registration isn't found in the "scope to registration map"
- Synchronously (before enqueuing a job) check for an existing newest worker
- Synchronously check if an installing worker is attempting to update itself
Differential Revision: https://phabricator.services.mozilla.com/D41618
--HG--
extra : moz-landing-system : lando
The args are sent from the parent process main thread to the parent process
background thread and then from the background thread to a content process
worker launcher thread.
Differential Revision: https://phabricator.services.mozilla.com/D26173
--HG--
extra : moz-landing-system : lando
Testing declared segments is a bit tricky until we support
'ref.func'. For now, I've written some basic tests.
Differential Revision: https://phabricator.services.mozilla.com/D40585
--HG--
extra : moz-landing-system : lando
As the following commit explained, this change isn't backwards compatible with
the existing implementation and the spec tests needed to be modified.
I've written a stub commit to the spec interpreter to encode/decode element
segments well enough to pass the current spec tests, and did another
import of the tests. The commit can be found here [1] [2].
[1] https://github.com/eqrion/spec/tree/spidermonkey-tree-tests
[2] d81e3cfe6e
Differential Revision: https://phabricator.services.mozilla.com/D40584
--HG--
extra : moz-landing-system : lando
The element segment changes are backwards compatible with the MVP, but not the
existing implementation. Some tests needed to update their expectations or
binary encoding.
Differential Revision: https://phabricator.services.mozilla.com/D40583
--HG--
extra : moz-landing-system : lando
Issue: https://github.com/WebAssembly/bulk-memory-operations/issues/98
This commit updates the encoding of element segments to the latest bulk-memory
proposal. This is backwards compatible with the MVP, but a breaking change from
the previously implemented bulk-memory spec.
The following semantic differences are made with the new encoding.
1. The introduction of 'Declared' segments
* Declared segments allow a Wasm module to forward declare which
functions are aliasable by ref.func. See reference-types#31 for more
information.
2. Whether an element expression or function indices are encoded now depends
on an independent flag from the 'kind' of an element segment.
3. The definition kind or element expression type is now explicitly encoded
in the element segment.
Differential Revision: https://phabricator.services.mozilla.com/D40582
--HG--
extra : moz-landing-system : lando
Issue: https://github.com/WebAssembly/bulk-memory-operations/issues/98
This commit updates the decoding of element segments to the latest bulk-memory
proposal. This is backwards compatible with the MVP, but a breaking change from
the previously implemented bulk-memory spec.
The following semantic differences are made with the new encoding.
1. The introduction of 'Declared' segments
* Declared segments allow a Wasm module to forward declare which
functions are aliasable by ref.func. See reference-types#31 for more
information.
2. Whether an element expression or function indices are encoded now depends
on an independent flag from the 'kind' of an element segment.
3. The definition kind or element expression type is now explicitly encoded
in the element segment.
A following commit will update the in-tree wat2wasm encoder.
Differential Revision: https://phabricator.services.mozilla.com/D40581
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Jon Coppeard
Mirko Brodesser
dlee
Sylvestre Ledru
Dale Harvey
Makoto Kato
Paul Zuehlcke
Cosmin Sabou
Mike Hommey
Narcis Beleuzu
Perry Jiang
Ed Lee
Junior Hsu
Ryan Hunt
Brindusan Cristian