There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
Any callers do not refer "ignored", "handled" and "cancel" state without
checking whether the method returns error or not. Therefore, error state
can be (and should be) managed by `mozilla::Result`'s error state.
Perhaps, it should store a caret position later because deletion handlers
of `HTMLEditor` use it, but update `Selection` immediately.
Differential Revision: https://phabricator.services.mozilla.com/D158080
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
Unfortunately, it's hard to split this (and similar) patch because we need to
touch `MoveNodeResult` itself for making it available as the ok type of
`Result`. However, I guess that it's not so hard to investigate regression
point if something would be found later because `MoveNodeResult` is mainly
used by deletion which is the most complicated part of `HTMLEditor`, but
`MoveNodeResult` is used only in a few cases.
Differential Revision: https://phabricator.services.mozilla.com/D157574
This is a hack for compatibility with the other browsers. When we move first
line of `<pre>` to left paragraph whose `white-space` style does not make it
preformatted, they drop the last linefeed because of unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D157419
It splits inline elements at the destination of first line in the right block.
However, it typically creates empty inline elements before the right block and
may be never used because it sets the insertion point to before the right node
of the splitting.
Therefore, it should stop creates empty inline elements (if they are required,
they should be created in `HTMLEditor::MoveNodeOrChildrenWithTransaction`
instead) and adjust split point after the element if it didn't split any nodes.
Differential Revision: https://phabricator.services.mozilla.com/D157418
When the first line of right block element is moved before the block element,
unnecessary line break may be moved to immediately before the right block
element. In the case, it needs to clean it up instead of trying to find
unnecessary line break at end of the left block which is a container of the
right block element.
Differential Revision: https://phabricator.services.mozilla.com/D157417
Empty inline nodes except non-container nodes are not required in the
destination paragraph. Therefore, it should just remove the node from the
DOM tree.
Differential Revision: https://phabricator.services.mozilla.com/D157416
We don't ignore invisible data node at joining 2 paragraphs and this is
a different behavior from the other browsers. When looking for a content
from current block boundary, `AutoBlockElementsJoiner` should keep scanning
visible things with ignoring invisible data nodes. Then, it should delete
all invisible things after joining the paragraphs.
Differential Revision: https://phabricator.services.mozilla.com/D157414
Chrome and Safari preserve `white-space` with `style` attribute to keep
collapsible or preserved white-spaces as-is. If an HTML element is moved,
`style` attribute should be set to it. Otherwise, create `<span>` element
whose `style` attribute has the declaration for `white-space` and move
content into it.
Differential Revision: https://phabricator.services.mozilla.com/D157413
Gecko just joins 2 blocks when editable block parents are same element, e.g.,
both are `<div>`. However, Chrome and Safari moves only first line of the
right block into the left block, and Gecko does it when both blocks are
different elements.
Ideally, we should take same behavior as Chrome and Safari because it's
reasonable for both compatibility with the other browsers and consistency
when both blocks are different but has same style, then we don't need to
maintain different behavior paths.
However, doing it for all elements are too risky because right block will be
merged into left block if right block has no line break. On the other hand,
without doing it, preserving `white-space` is really hard because we need to
maintain the both paths.
Therefore, I'd like to change the behavior only when both blocks have different
`white-space` styles. Usually, web apps do not change `white-space` for each
block, so I think that this is safer than doing this in all elements,
additionally, we can revert the behavior easy since this patch is really small.
Differential Revision: https://phabricator.services.mozilla.com/D157412
This fixes bug 503838 partially. The new utility method scans unnecessary
`<br>` with strict check as far as possible. Then, we can delete the node or
the preformatted line break at end of the last text node.
Differential Revision: https://phabricator.services.mozilla.com/D157411
This patch ports most part of `editor/libeditor/tests/test_bug772796.html` to
WPT because this kind of behaviors are not tested by `editing/run/delete.html`
nor `editing/run/forwarddelete.html`. (Not ported tests are invalid HTML
structure cases and list item cases, the reason why not doing this for the
latter is, it needs a lot of cases and not important for most web apps.)
The most expectations are based on Chrome and Safari (they both behave almost
same), but they fail a lot in `join-pre-and-other-block.html` and
`white-space: pre-line` cases in the other tests.
Even though this ports a lot of cases, for making easier to compare the
behavior change in the following patches, we should keep the tests.
Differential Revision: https://phabricator.services.mozilla.com/D157410
The line never runs in automated tests, and
`RemoveBlockContainerElementsWithTransaction` does not check whether the DOM
tree gets as expected or not. Therefore, I have no idea how to test this.
Differential Revision: https://phabricator.services.mozilla.com/D157573
It may be called even when there is no selection range and focused element.
However, it assumes that there is a selection range, and an editable element
has focus. Therefore, now, if there is an editing host and user tries to
do "Select All" without clicking somewhere before doing it, "Select All" does
nothing.
Differential Revision: https://phabricator.services.mozilla.com/D157409
They and their callees work with the result of `GetRoot()` which is the document
element or the body element. If the body is not editable, `Selection` should
not be updated in non-editable region nor `<br>` elements should not be
inserted in both non-focused editable elements and non-editable elements.
Therefore, they should run only when the document element or the `<body>`
element is editable.
To keep testing crashtests as reported, this patch makes tests which have
`contenteditable` except `<html>` and `<body>` initialize `Selection` as
what we've done. And clean up the tests for helping to port them to WPT
in the future (bug 1725850).
Differential Revision: https://phabricator.services.mozilla.com/D157408
It does different thing for `TextEditor` and `HTMLEditor`, and used almost
internally. Therefore, it should be implemented in the sub classes and
we should name them better.
Differential Revision: https://phabricator.services.mozilla.com/D157407
The method is enough simple, and uses bad cast from point of view of OOP.
Therefore, this patch make the sub classes implement the method only for each.
Differential Revision: https://phabricator.services.mozilla.com/D157406
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
The method is enough simple, and uses bad cast from point of view of OOP.
Therefore, this patch make the sub classes implement the method only for each.
Differential Revision: https://phabricator.services.mozilla.com/D157406
It does different thing for `TextEditor` and `HTMLEditor`, and used almost
internally. Therefore, it should be implemented in the sub classes and
we should name them better.
Differential Revision: https://phabricator.services.mozilla.com/D157407
The method is enough simple, and uses bad cast from point of view of OOP.
Therefore, this patch make the sub classes implement the method only for each.
Differential Revision: https://phabricator.services.mozilla.com/D157406
Unfortunately, the result is really different from the other browsers.
E.g., when `execCommand("indent")` at `<div>abc<br>{}<br></div>`, Gecko inserts
a `<div>` and set its `margin-left`. However, Chrome splits parent `<div>`
element and wrap the `<div>` which contains the caret in new `<blockquote>`.
Therefore, this does not contain new WPT.
Depends on D157404
Differential Revision: https://phabricator.services.mozilla.com/D157405
These macros will produce better outputs when they fail than these existing
patterns using `ENSURE_TRUE(NS_SUCCEEDED(...))` or similar, so this is a bulk
rewrite of existing tests to use them.
It should also help with discoverability when people base their tests off of
other existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D157214
After this change, it's possible to set the pref, or use editor.document.execCommand("styleWithCSS", false, "true") to enable css in mail compose.
Differential Revision: https://phabricator.services.mozilla.com/D157276
When selection is `abc<b>[def</b>]ghi`, `insertParagraph` command will delete
the `<b>` element first, then, `Selection` becomes `abc{}ghi`. Then,
`HTMLEditor::InsertParagraphSeparatorAsSubAction` wraps all of the line in
the default paragraph, `<div>`, with
`HTMLEditor::FormatBlockContainerWithTransaction` (although this is incompatible
behavior with the other browsers). At this time, new `<div>` is inserted before
the first text node and then, move the text nodes into the new `<div>`.
However, `RangeUpdater::DidMoveNode` just slides the offsets if containers of
registered DOM points are the ex-parent of the moving nodes. Therefore, the
tracked selection range in `HTMLEditor::FormatBlockContainerWithTransaction`
become `<div></div>abc{}def`, then, `<div>abcdef</div>{}`, but the expected
behavior is of course, `<div>abc{}def</div>`, then, split the new `<div>`.
So the problem is, `DidMoveNode` assumes that DOM points won't point the moving
content node. If the node is pointed, it should keep pointing in the new
parent.
Note that the expectations of new tests are based on Chrome, therefore, the
new known failures are incompatible with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D156798
It's hard to know how some tests failed in test_bug1318312.html. Therefore,
this patch makes the selection range comparison easier to read, and add
description to explain what was doing at the failure.
Differential Revision: https://phabricator.services.mozilla.com/D156526
This patch fixed a regression caused by Bug 1730084 Part 4
https://phabricator.services.mozilla.com/D125434, which is intended to preserve
the behavior of `WordBreaker::FindWord()`.
Before Bug 1730084 Part 4, `WordBreaker::FindWord()` returns
`[aTextLen + 1, aTextLen + 1]` only when `aOffset > aTextLen`.
But `WordBreaker::FindWord()` had an assertion `aOffset <= aTextLen`
to guarantee the caller never passes `aOffset > aTextLen`. Thus, we can never
go into the `if (res.mBegin > strLen)` in
`TextServicesDocument::OffsetEntryArray::FindWordRange()`.
However, Bug 1730084 Part 4 wrongly changes the if-statement to
`if (range.mEnd == range.mBegin)`, and makes it reachable when
`TextServicesDocument::OffsetEntryArray::FindWordRange()` passes
`aPos == aLen` into `WordBreaker::FindWord()`. This makes `InitSpellChecker()`
failed when `enableSelectionChecking=true`.
This patch deletes the originally unreachable error handling if-statement, and
adds an assertion to guarantee `strOffset` and `strLen` is valid.
Differential Revision: https://phabricator.services.mozilla.com/D156210
Additionally,
* `PropItem` -> `PendingStyle`
* `StyleCache` -> `PendingStyleCache`
* `AutoStyleCacheArray` -> `AutoPendingStyleCacheArray`
And finally, `PendingStyle` (formally `PropItem`) is changed to `class` and
its members are encapsuled.
Differential Revision: https://phabricator.services.mozilla.com/D155318
For consistency with the previous patch, we should rename them too. Then, we're
getting rid of unclear word "Prop" from the public methods.
Differential Revision: https://phabricator.services.mozilla.com/D155316
I usually retry to understand what they mean. Therefore, I'd like to give new
names for them (and rename `TypeInState` class in a following patch).
Differential Revision: https://phabricator.services.mozilla.com/D155315
Only the value member needs to be updated when setting the prop multiple times.
Therefore, we cannot change all members to constants.
Differential Revision: https://phabricator.services.mozilla.com/D155313
According to the debug, its value can be CSS property value if in the CSS mode.
For making the value meaning easier to understand, this renames it to
mAttributeValueOrCSSValue.
Differential Revision: https://phabricator.services.mozilla.com/D155312
It's currently no problem to manage it with a raw pointer because it may be
set to a dynamic atom only when `nsIHTMLEditor.insertLinkAroundSelection` is
called with unknown attribute, but comm-central uses it only with `href`
attribute.
I think that we should change the API just to take `href` value in the future,
but for now, it should be `RefPtr<nsAtom>`.
Differential Revision: https://phabricator.services.mozilla.com/D155311
It's always a pointer to `nsStaticAtom` instance or `nullptr`. Therefore,
it can be `nsStaticAtom*` and we can make its users treat `nsStaticAtom`
instead of `nsAtom`.
Additionally, this patch changes some pointer parameters to references if
they are never `nullptr`.
Differential Revision: https://phabricator.services.mozilla.com/D155310
In bug 1739524, I misunderstood the meaning of `aOffset` of `SelAdjJoinNodes`.
After joining 2 nodes, and a point points right node which will have ex-left
node content, the point needs to point ex-start of the right node to keep
next insertion point as-is. Therefore, it's not useful with new join nodes
direction, it needs to know the ex-offset of the right node.
Differential Revision: https://phabricator.services.mozilla.com/D155438
Before the fix of bug 1758420, `TextComposition`'s text node and offset in it
are updated at creating `CompositionTransaction`. However, it's now put off
until getting the mutations. Therefore, it always unsets `pointToInsert` at
first time of the composition and fails to notify the listeners.
This patch makes it retrieve the result after calling `DoTransactionInternal`
and handle the post processing with the new point.
Differential Revision: https://phabricator.services.mozilla.com/D155052
This patch doesn't impact behavior.
The pref "gfx.font_loader.interval" used to control certain aspects of
font-loading behavior, but that code has evolved and we no longer read the
value of this pref anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D155183
It's a Gecko specific feature, and it sets background color of parent block
elements of selection ranges. This does similar things to
`SetInlinePropertiesAsSubAction`, but still refers `Selection` directly and
uses `AutoSelectionRestorer`. For consistency between similar methods, this
patch makes it use `AutoRangeArray`.
Depends on D154353
Differential Revision: https://phabricator.services.mozilla.com/D154354
`HTMLEditor::RelativeFontChange()` and its helpers are based on
`SetInlinePropertiesAsSubAction()` and its helpers. Therefore, they may have
similar problem to switch join/split direction. Therefore, this and the
following patches clean them up too.
Depends on D154350
Differential Revision: https://phabricator.services.mozilla.com/D154351
I think that `HTMLEditor::SetInlinePropertyAsSubAction` and
`HTMLEditor::RemoveInlinePropertyAsSubAction` should not be called multiple
times in one edit action. Therefore, I'd like to make them take multiple
styles once. Then, we could collect all targets before touching the DOM tree
in the future.
Depends on D154348
Differential Revision: https://phabricator.services.mozilla.com/D154349
This is a pre-fix for bug 1735608. Currently, the loop assumes that collected
nodes are always right node, but it'll be changed, therefore, it creates
new array for the follow up loops handle expected nodes.
Depends on D154346
Differential Revision: https://phabricator.services.mozilla.com/D154347
I'd like to get rid of `AutoSelectionRangeArray` and `AutoRestoreSelection`,
and I'd like to make it stop touching `Selection` while it is removing style
of each content nodes in the range. Therefore, this patch rewrites it with
`AutoRangeArray`. Then, we can reduce the indent level of the nested `for`
loops.
Note that it creates `AutoEditSubActionNotifier`, so it's a sub-edit action
handler. Therefore, this patch renames it.
Depends on D154345
Differential Revision: https://phabricator.services.mozilla.com/D154346
I've already made a caller of `HTMLEditor::ClearStyleAt`,
`HTMLEditor::CreateStyleForInsertText`, in bug 1770877, so this fixes a bug of
the patch.
`HTMLEditor::ClearStyleAt` is still updates `Selection` only in some cases.
And one of the caller has not handle the `Selection` update. Therefore, once
it completely stop touching `Selection`, `ComputeEditingHost` will fail and
the other paths update `Selection`, so it should do it too. (Without the
change, `test_dragdrop.html` fails.)
Finally, we don't need `EditResult` anymore because we have
`Result<EditorDOMPoint, nsresult>`.
Differential Revision: https://phabricator.services.mozilla.com/D154343
Similar to the previous patch, and for consistency between editor helper
classes, we should make result of getter methods of `EditorDOMPointBase` too.
Differential Revision: https://phabricator.services.mozilla.com/D153841
We'll need the version to return `dom::Text*` in coming patches for bug 1735608.
For avoiding the class to have a lot of getters, we should make result of the
getters templated.
Differential Revision: https://phabricator.services.mozilla.com/D153840
`GetLeftContent()` etc is explained as:
> This may return nullptr if the method didn't split at start edge of the node.
On the other hand, `SplitNodeResult::GetPreviousContent()` and
`SplitNodeResult::GetNextContent()` returns previous or next content node
of split point when the split is not performed, but not in error.
Therefore, it should check `SplitNodeResult::DidSplit()` instead of
`SplitNodeResult::isOk()`.
However, there is another problem. The constructor cannot specify the order
of the 2 splits. Therefore, it's hard to maintain the constructor.
Fortunately, there is only one user, so we can make the user create the
result with another constructor.
Differential Revision: https://phabricator.services.mozilla.com/D153838
If splitting node creates new right node instead of new left node,
`TopLevelEditSubActionData::mChangedRange` ends by start of the right node.
However, `RemoveEmptyNodesIn` uses `PostContentIterator` which collects DOM
nodes whose "end tag" appear in the range. Therefore, for cleaning up new
empty right nodes correctly, we need to extend the range to contain the node.
Additionally, it removes unexpected element which is editable but shouldn't be
removed from the DOM tree. Therefore, this patch adds new check such as
`HTMLEditUtils::IsRemovalNode()`.
Finally, this patch adds a check whether the editor is a mail editor or not
at considering whether a node is a "mail-cite" because `contenteditable` in
web apps do not need special handling for such Gecko-specific element.
Differential Revision: https://phabricator.services.mozilla.com/D153834
The test oddly passes without the fix in `HandleInsertBRElement`. I guess that
post-processing in `HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal()`
handles `Selection`, and anyway the insertion point of the following
`insertText` is wrong. It seems that we don't need to uplift this.
Differential Revision: https://phabricator.services.mozilla.com/D153832
`increaseFontSize`, `decreaseFontSize`, `gethtml`, `heading` and `readonly`
commands were disabled for a year in all channels, but no regression reports
have been filed. Therefore, we can delete the commands and the telemetry
probes.
Note that `cmd_getContents` command which is the internal command of `gethtml`
is not used in comm-central too. Therefore, this patch deletes the command
handler, `nsClipboardGetContentsCommand`, and `Command::GetHTML` too.
Differential Revision: https://phabricator.services.mozilla.com/D153720
For doing that, this patch also making `HTMLEditor::AlignContentsAtSelection`
which the only caller of `HTMLEditor::AlignNodesAndDescendants` handle
`Selection` with `AutoRangeArray` because it uses `AutoSelectionRestorer` and
we need to adjust `Selection` after restored.
Differential Revision: https://phabricator.services.mozilla.com/D152980
It's only caller is `HTMLEditor::AlignContentsAtSelection` which is called only
by `HTMLEditor::AlignAsSubAction` at almost last of it. Therefore, it's safe
to handle `mNewBlockElement` at the caller of
`AlignContentsAtSelectionWithEmptyDivElement` is safe.
Differential Revision: https://phabricator.services.mozilla.com/D152978
The change of expected assertion count in the crash test is caused by that the
test calls `execCommand` recursively from the legacy mutation event listeners.
Therefore, stopping updating `Selection` for each DOM tree change causes that
the target range in the nested edit action is changed. However, the nested
handling has already been disabled by default, so this should not be a problem
for the users.
Differential Revision: https://phabricator.services.mozilla.com/D152973
It's called only by `HTMLEditor::HandleCSSIndentAtSelection` which is called
only by `HTMLEditor::HandleIndentAtSelection`. They don't touch `Selection`
after calling it. Therefore, we can make it adjust collapsing selection point
by itself.
Differential Revision: https://phabricator.services.mozilla.com/D152972
With taking an `AutoRangeArray` which is initialized with `Selection`, it can
restore selection and check if it's collapsed and if collapsed in the expected
list element. Then, its caller can apply the returned range to `Selection`
because it's an edit sub-action handler.
Differential Revision: https://phabricator.services.mozilla.com/D152969
It oddly retrieve an ancestor list element which contains one range in the
selection ranges. So, working it with `AutoRangeArray` which is initialized
with `Selection` makes `HTMLEditor` smaller...
Differential Revision: https://phabricator.services.mozilla.com/D152966
They set `TopLevelEditSubActionData::mNewBlockElement` and their root callers
in edit sub-action level are only `InsertParagraphSeparatorAsSubAction` and
`FormatBlockContainerAsSubAction`, and they are called each other. Therefore,
this patch changes these 3 methods once.
Differential Revision: https://phabricator.services.mozilla.com/D152964
The following patches touch the logic to restore selection after handling
commands. However, it seems that they are not tested because I found some
regressions by manual testing, but didn't cause orange on tryserver.
`outdent-preserving-selection.tentative.html` causes a crash due to the
`MOZ_ASSERTION` in `HTMLEditor::HandleOutdentAtSelectionInternal`. It means
that I misunderstand the logic and had put the assertion. I should fix it
later with reading the complicated code again. For now, I just change it
to `NS_WARNING_ASSERTION` instead.
And also `test_cmd_absPos.html` is the first test to check toggling `position`
between `static` and `absolute`. Therefore, it detects wrong `MOZ_ASSERT`s
which test whether `EditActionData` or `TopLevelEditSubActionData` is created
or not **before** they create them by themselves. So, this patch removes the
wrong assertions.
Differential Revision: https://phabricator.services.mozilla.com/D152962
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
Currently, `HTMLEditor` assumes that padding `<br>` element for empty last line
is outside of inline elements, but it may happen because of both:
* starting from bug 1778091, `HTMLEditor` move `<br>` element into new empty
inline elements at inserting new paragraph.
* web apps can put it into inline elements.
After splitting inline elements and which do not have meaningful content, users
cannot put caret into the empty inline elements so that the elements stay unless
delete around there.
For avoiding the leak due to meaningless elements, we should delete them at
splitting inline elements at inserting new text.
Note that Chrome does not pass the new tests of resetting ancestor bold style
because Chrome wraps the `<b>` with `<i>`, however, the `<i>` has odd
`style=""`. Perhaps, the test framework should ignore it because it's not
important for the web-compatibility.
On the other hand, Chrome completely fails only the last testcase since it
unwraps the `<b>` from the last `<br>`, so the bold style which was applied by
the web app to the last `<br>` is lost. This is not reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D152616
Masayuki Nakano
Andrew McCreight
Butkovits Atila
Andreea Pavel
Jan-Niklas Jaeschke
Iulian Moraru
Nika Layzell
Magnus Melin
Ting-Yu Lin
Makoto Kato
Mark Banner
Daniel Holbert
André Bargull
Tooru Fujisawa