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
`BlocksRingBuffer` will be used both inside and outside `ProfileBuffer`:
- Inside to serve as `ProfileBuffer`'s main storage for stack traces,
- Outside to allow marker storage even when `ProfileBuffer` is locked during
stack sampling.
`ProfileBuffer` only exists while `ActivePS` is alive, but because of the
potential outside accesses above (due to small races between ProfileBuffer
shutdown, and thread-local IsBeingProfiled() flags), we cannot just do the same
for BlocksRingBuffer, and it must remain alive to gracefully deny these accesses
around the profiler startup and shutdown times.
To accomplish this, `BlocksRingBuffer` may be in different states:
- "In-session", we have a real buffer to write to and read from,
- "Out-of-session", without buffer so reads&writes do nothing.
This is implemented by enclosing the underlying `ModuloBuffer` and the entry
deleter in a `Maybe`, which may be `Nothing` when the profiler is not running
and the `ProfileBuffer`'s `BlocksRingBuffer` is out-of-session.
Differential Revision: https://phabricator.services.mozilla.com/D41519
--HG--
extra : moz-landing-system : lando
`TextEditRules` and `HTMLEditRules` still refer
`EditorBase::mPaddingBRElementForEmptyEditor` directly but this is really ugly.
Therefore, this patch creates `EditorBase::HasPaddingBRElementForEmptyEditor()`
for wrapping its access.
Differential Revision: https://phabricator.services.mozilla.com/D41162
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::OnModifyDocument()` is same as just calling
`EditorBase::EnsureNoPaddingBRElementForEmptyEditor()` and
`EditorBase::MaybeCreatePaddingBRElementForEmptyEditor()` so that this patch
gets rid of the method, then, creates `HTMLEditor::OnModifyDocumentInternal()`
and makes it do same thing.
Differential Revision: https://phabricator.services.mozilla.com/D41161
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::WillLoadHTML()` does exactly same thing as
`EditorBase::EnsureNoPaddingBRElementForEmptyEditor()`. Therefore, we can
get rid of it and make `HTMLEditor::LoadHTML()` not use `HTMLEditRules`.
Differential Revision: https://phabricator.services.mozilla.com/D41160
--HG--
extra : moz-landing-system : lando
`TextEditRules::CreatePaddingBRElementForEmptyEditorIfNeeded()` is used by
both `TextEditor` and `HTMLEditor` so that this moves it into `EditorBase`.
Additionally, making `TextEditor::MaybeChangePaddingBRElementForEmptyEditor()`
call it if there is no content. Then, we can avoid the dependency of them.
Differential Revision: https://phabricator.services.mozilla.com/D41159
--HG--
extra : moz-landing-system : lando
`TextEditRules::RemoveRedundantTrailingBR()` is used only by multiline text
editor (i.e., `<textarea>`). Therefore, it should be moved into `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D41158
--HG--
extra : moz-landing-system : lando
`TextEditRules::WillUndo()` and `TextEditRules::WillRedo()` only check whether
the editor is readonly/disabled or not. So, `TextEditor::UndoAsAction()` and
`TextEditor::RedoAsAction()` should do it first.
`TextEditRules::DidUndo()` and `TextEditRules::DidRedo()` only set or unset
`mPaddingBRElementForEmptyEditor` if it's restored by undo or redo.
Therefore, we can move the code into `TextEditor::UndoAsAction()` and
`TextEditor::RedoAsAction()`.
Note that this patch makes `TextEditor::UndoAsAction()` discard the result of
`TransactionManager::Undo()` because this is inconsistent from what
`TextEditor::RedoAsAction()` does and this was changed by part 5 of bug 1447924.
https://hg.mozilla.org/mozilla-central/rev/869a1445816be7f43f54f7c97f28e4c6273fa75f
Differential Revision: https://phabricator.services.mozilla.com/D41157
--HG--
extra : moz-landing-system : lando
`TextEditRules::WillInsert()` is not used with initial purpose since
`HTMLEditor` always works with `HTMLEditRules` and its `WillDoAction()`
always handles `EditSubAction::eInsertElement`.
Additionally, its name is too generic since it does non-related 3 things.
One is checking whether the editor is readonly or disabled. However, this
may not be necessary since its callers may have already checked it or
just ignored the result. So, this should be check by each caller.
Next one is masking password if auto-masking is enabled. This is `TextEditor`
specific feature so that this patch moves the code into
`TextEditor::MaybeDoAutoPasswordMasking()`.
Final one is removing empty `<br>` element for empty editor if there is.
This is common feature so that this patch moves this code into
`EditorBase::EnsureNoPaddingBRElementForEmptyEditor()`.
Differential Revision: https://phabricator.services.mozilla.com/D41156
--HG--
extra : moz-landing-system : lando
`TextEditRules::mPaddingBRElementForEmptyEditor` are used by both `TextEditor`
and `HTMLEditor`. Therefore, it should be in `EditorBase`.
This patch makes `TextEditRules` and `HTMLEditRules` directly access the
private member of `EditorBase` temporarily. It'll be fixed by the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D41155
--HG--
extra : moz-landing-system : lando
This also applies the error listener just to the Javadoc tasks
(previously, it applied to the `apiGenerate*` tasks as well, 'cuz they
inherit from `Javadoc`).
Differential Revision: https://phabricator.services.mozilla.com/D41634
--HG--
extra : moz-landing-system : lando
With this patch, tiles that are covered only by the opaque backdrop
primitive are detected and noted as solid colors.
Solid color tiles save memory and performance, because:
- No texture slice is allocated as a render target for them.
- No need to rasterize this tile.
- Drawing the tile is done with the faster rectangle shader.
This already saves performance and GPU memory on quite a few
real world sites (esp. when running at 4k). However, the main
benefit of this will be once we enable picture caching on
multiple content slices and the UI layer. When this occurs, it's
important to avoid allocating tile buffers for all the solid
rectangle tiles that the UI layer typically contains.
Differential Revision: https://phabricator.services.mozilla.com/D41342
--HG--
extra : moz-landing-system : lando
For accessibility, the address bar is now exposed as a parent combo box which contains the input and the results list.
The combo box role on urlbarView-body-inner is no longer needed and has therefore been removed.
This means screen readers no longer report an extraneous combo box whenever the results list is opened.
Differential Revision: https://phabricator.services.mozilla.com/D40917
--HG--
extra : moz-landing-system : lando
Allow access to timezone data files from the content/flash/GMP/utility sandbox.
Remove unneeded regex providing access to ^/private/tmp/KSInstallAction\. files.
Differential Revision: https://phabricator.services.mozilla.com/D41455
--HG--
extra : moz-landing-system : lando
