With the branch 64 update we no longer configure packet size and rate
ourselves. Instead, we use the defaults provided in acm_codec_database.cc.
This removes the unused fields from AudioCodecConfig, the next commit does the
same thing for JsepAudioCodecDescription.
Differential Revision: https://phabricator.services.mozilla.com/D12012
--HG--
extra : moz-landing-system : lando
Summary:
Adds some missing braces on if structures
Adds a check for i being larger or equal to nb
Reviewers: rstrong
Reviewed By: rstrong
Bug #: 1468542
Differential Revision: https://phabricator.services.mozilla.com/D12193
--HG--
extra : rebase_source : 51a99f5376ed8877162e82b6c15f147df81981f8
Resetting the entered count on an IC stub chain makes interpretation of the
counter values easier. For example, if we see an IC chain like this
A (1000) -> B(800) -> C (400) -> D (200) -> FB (100)
We can say that there have been 100 cases not handled by chain, (and we did
not attach new stubs for those cases), and B handled the most (400) queries
to the IC chain.
Differential Revision: https://phabricator.services.mozilla.com/D11883
--HG--
extra : moz-landing-system : lando
Rename MOZ_MakeRecordReplayWrapper to MOZ_MAKE_RECORD_REPLAY_WRAPPER so
that clang-format doesn't mangle code.
Differential Revision: https://phabricator.services.mozilla.com/D12233
--HG--
extra : moz-landing-system : lando
As we were using the browserWindow to start the
parser worker, this was causing an exception
when evaluation from the browser toolbox.
Using chromUtilsWindow fixes the issue.
There is no tests yet as I'm not sure there's
an easy way to test things in the browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D12101
--HG--
extra : moz-landing-system : lando
Protect tabular macros or struct initializers that can mangled by
clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D12239
--HG--
extra : moz-landing-system : lando
Add JS_FOR_PROTOTYPES_ macro that takes REAL_IF_SAB, etc helpers to
handle conditional proto keys. This is easier to read and avoids macro
expansion issues confusing clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D12238
--HG--
extra : moz-landing-system : lando
When calling nsGlobalWindowOuter::SetOpenerWindow with null we should
make sure to also clear BrowsingContext::mOpener.
Differential Revision: https://phabricator.services.mozilla.com/D11769
--HG--
extra : moz-landing-system : lando
This pref is left over from B2G days. It is currently disabled for firefox
desktop, but not for Android. This didn't affect us until now because we
always ran Android tests in non-e10s mode.
The pref ought to be removed in bug 1306801.
Differential Revision: https://phabricator.services.mozilla.com/D12293
--HG--
extra : moz-landing-system : lando
This pleases clang-format and makes many of these behave better when
auto formatted. Special cases may still be marked |clang-format off| in
later commits.
Differential Revision: https://phabricator.services.mozilla.com/D12231
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests[css-properties-values-api] Support fallbacks.
According to css-variables-1, any custom property that participates in a
cycle is invalid. This also applies to registered custom properties.
In the current implementation, however, registered custom properties
with an initial value can not become invalid; they compute to their initial
value instead, as provided by registerProperty. A consequence of this, is
that fallbacks (specified by var()-references) are never triggered if the
referenced property is a registered property with an initial value defined.
The value for any unregistered custom property, if no other value is
specified, is the invalid initial value described by css-variables-1.
This means we can just avoid storing the variable on ComputedStyle, to
signify the invalid initial value.
However, the value for any registered custom property, if no other value is
specified, can be the initial value specified by registerProperty. When
there is no value explicitly stored on ComputedStyle, we check
StyleInitialData and fetch the initial value from there. Hence, we can not
use the absence of a value to signify an invalid registered variable, as
we already use this state to mean "initial value from registerProperty".
This means that we must explicitly store a value for registered properties
that participate in a cycle. This CL adds CSSInvalidVariableValue to do
this.
* When resolving a registered custom property, if a cycle is detected, set
the registered value to CSSInvalidVariableValue.
* When looking up a registered custom property, if we already have the
value CSSInvalidVariableValue, return nullptr instead of initial data.
This triggers fallbacks.
* The code that set the cycle_detected flag was weird; a cycle could be
marked as detected, even though ResolveTokenRange succeeded. This meant
that any custom property which referenced a property in a cycle would
also be treated as part of the cycle, which is wrong. Fixed by only
setting the cycle_detected flag when we have cycle start points.
* CSSInterpolationType did not initialize its cycle_detected variable,
which led to undefined behavior.
R=futhark@chromium.org
Bug: 641877
Change-Id: I2c518b176de26f7b2f05b36b568041a228fcb0ea
Reviewed-on: https://chromium-review.googlesource.com/c/1333758
Commit-Queue: Anders Ruud <andruud@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608014}
--
wpt-commits: f082fd63300fec7b6201cf5e0eaf0944ee7ccb6e
wpt-pr: 14039
Automatic update from web-platform-testsFix background image painting of very small images
The background image fast path painting rounds the image src rect
to integer sizes assuming sprite maps and/or reasonably large images.
When a very small image is used scaled up to a large size (such as
constant color images scaled up to form progress bars by animating
background size) the src rect may be 1 x [small number] which gets
rounded to zero size.
This patch changes the code to detect this situation and not round
in such cases.
It's worth recording that an alternate approach is to detect when
the rounding results in a significant change in src rect and always
switch to unrounded in that case. But it would be more expensive for
a relatively uncommon case.
R=fmalita
BUG=904042
Change-Id: I24657a5d087c0dda0fd8a5e3c3d08e1e4eb02473
Reviewed-on: https://chromium-review.googlesource.com/c/1334291
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607901}
--
wpt-commits: e1a59fb1af26d892ffee739205d1ab536d0d2819
wpt-pr: 14042
