The logic here intends to (as is written in the comment) append one block of
silence to the track to allow for us to underrun one full scratch buffer.
The code doesn't match this behavior however, because if we are not underrunning
by less than a block, we end up appending *less* than a block. This causes us to
append at a later time as the scratch buffer can swallow more (up to a full
block) than we appended.
Without processing this seems to work because of timing and ordering, but
with processing (aec/agc/ns) we tend to add 71
(512 for an iteration - 441 packed) samples of silence,
leaving us to hit the assert with a 44% ((128-71)/128) chance during subsequent
iterations.
Differential Revision: https://phabricator.services.mozilla.com/D2644
--HG--
extra : moz-landing-system : lando
mozInlineSpellChecker::ReplaceWord() is used for replacing misspelled word
with a word. So, this is necessary to be distinguished from insertText
command when we implement InputEvent.inputType. So, we should make it
use TextEditor::ReplaceTextAsAction() instead (same as autocomplete).
This patch makes TextEditor::ReplaceTextAsAction() take optional argument
to make callers can specify replace range. Then, the range is a spellchecker
selection range if the caller is mozInlineSpellChecker::ReplaceWord().
Prior to this patch, it clones the range for normal selection, but it's
expensive and we may be able to reuse cached range of Selection in this case.
So, this patch makes Selection::AddRangeInternal() checks if given range is
in another Selection and use mCachedRange as far as possible.
MozReview-Commit-ID: JIOTTsxlj4Q
--HG--
extra : rebase_source : 7c26b0255f08608ebe8c7045c9bcdca1dc70cadf
InputEvent.inputType needs to distinguish whether inserting text is caused
by insertText command or replaced by autocomplete or spellchecker.
Therefore, nsTextEditorState::SetValue() cannot use
TextEditor::InsertTextAsAction() nor TextEditor::DeleteSelectionAsAction().
This patch reuses TextEditor::SetText()'s slow path for the new method.
Note that the new method uses EditSubAction::eInsertText as top level edit sub-
action because specifying this improves undo/redo behavior.
And also this patch modifies test_bug1368544.html. Oddly, only on Android,
we get different result. After removing all text with setUserInput(""),
TextEditor::DeleteSelectionAsSubAction() removes both text node and non-bogus
<br> element from the anonymous-div element. However, only on Android, new
<br> element is recreated. I've not understood where this difference comes
from yet.
MozReview-Commit-ID: GKNksctGik
--HG--
rename : toolkit/content/tests/chrome/file_autocomplete_with_composition.js => toolkit/content/tests/chrome/file_editor_with_autocomplete.js
rename : toolkit/content/tests/chrome/test_autocomplete_with_composition_on_input.html => toolkit/content/tests/chrome/test_editor_for_input_with_autocomplete.html
rename : toolkit/content/tests/chrome/test_autocomplete_with_composition_on_textbox.xul => toolkit/content/tests/chrome/test_editor_for_textbox_with_autocomplete.xul
extra : rebase_source : b90419d9e5a01e86f6e6418f8df002c91416acae
Copy over non-rule font faces to the static clone document that is used
during printing.
MozReview-Commit-ID: 8ggNrCcVpEK
--HG--
extra : rebase_source : 27e270edd28c3ecf19a99f4df5398a89e6c53e6a
Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
AutoSafeJSContext enters the unprivileged junk scope, so CreateSandbox returned a wrapper and then we used the wrapper's global instead of the sandbox global. We now use AutoJSAPI with a null realm.
Mostly automatic via sed. Only parts which I touched manually (apart from a
couple ones where I fixed indentation or which had mispelled arguments) are the
callers. I may have removed a couple redundant `virtual` keywords as well when
I started to do it manually, I can revert those if wanted.
Most of them are just removing the argument, but in Element.cpp I also added an
assertion for GetBindingParent when binding the ShadowRoot's kids (the binding
parent is set from the ShadowRoot constructor, and I don't think we bind a
shadow tree during unlink or what not which could cause a behavior difference).
Differential Revision: https://phabricator.services.mozilla.com/D2574
MozReview-Commit-ID: 2oIgatty2HU
Always assume allowed-for-all-content. There are a couple callers which weren't
doing that:
* A unit test -> removed.
* ComputeAnimationDistance: Used for testing (in transitions_per_property), and
for the animation inspector. The animation inspector shouldn't show
non-enabled properties. The transitions_per_property test already relies on
getComputedStyle stuff which only uses eForAllContent.
* GetCSSImageURLs: I added this API for the context menu page and such. It
doesn't rely on non-enabled-everywhere properties, it was only using
eInChrome because it was a ChromeOnly API, but it doesn't really need this.
Differential Revision: https://phabricator.services.mozilla.com/D2514
MozReview-Commit-ID: 4VOi5Su3Bos
When a transceiver is stopped, its mid should not be reused by a new transceiver.
Differential Revision: https://phabricator.services.mozilla.com/D2518
--HG--
extra : moz-landing-system : lando
The constructor of WidgetCommandEvent takes 2 nsAtom pointers. One is for
specifying event type, the other is for specifying the command. The
difference of these arguments are pretty unclear for other developers and
the former argument is always nsGkAtoms::onAppCommand unless nullptr in
C++ code. So, we can hide the former argument.
Then, we should create another constructor for creating empty command event
from constructor of dom::CommandEvent.
Differential Revision: https://phabricator.services.mozilla.com/D2506
--HG--
extra : moz-landing-system : lando
