Bug 1547939 added a bunch of extra tests for three properties (background, mask,
and -webkit-mask). This made them time out more frequently in the Android
emulator.
Request a longer timeout to address this. Alternative is maybe just removing the
tests or such, I don't think they're of particularly great value.
Differential Revision: https://phabricator.services.mozilla.com/D29650
--HG--
extra : moz-landing-system : lando
Detect content process that already has connection to the RDD process
and don't attempt to relaunch or needlessly call
RDDProcessManager::CreateContentBridge. Calling CreateContentBridge
unnecessarily causes churn by recreating RemoteDecoderManagerParents.
Differential Revision: https://phabricator.services.mozilla.com/D29013
--HG--
extra : moz-landing-system : lando
This allows us to blacklist certain configurations. Previously we could only
use platform(...) which was more of a whitelist.
Differential Revision: https://phabricator.services.mozilla.com/D29729
--HG--
extra : moz-landing-system : lando
This makes some minor tweaks:
- Use a /sdcard/wrench/ folder for the args and reftests. For me bundling
the reftests as assets didn't work (app would panic trying to load those
files). Plus it seems better to not always bundle the reftests with the app.
- Always dump a full backtrace on Android
- Build both x86 and armv7 architectures of wrench into the same APK for
better compatibility.
- Update documentation.
Differential Revision: https://phabricator.services.mozilla.com/D29728
--HG--
extra : moz-landing-system : lando
As the purpose of adjusting time is to make the start of the playback to align to zero, so the result should not be negative.
However, we can't always ensure the demuxed start time is correct, the decoded first frame sample time might be different with the time demuxer provides.
Even if we try to update the start time when we get the first decoded sample, there is still a problem because a decoder might return samples with different order, which means the first frame the decoder returns is probably not a real first frame.
Therefore, using warning to help us knows how many this situaion would be.
Differential Revision: https://phabricator.services.mozilla.com/D28432
--HG--
extra : moz-landing-system : lando
Considering that the audio sample's time is always increased, the decoded sample's time decoder returns should always be equal or larger than its demuxed time.
When the decoded sample's time is smaller than the time of first demuxed sample, that time would probably cause a problem so we should throw an error for that.
Differential Revision: https://phabricator.services.mozilla.com/D28167
--HG--
extra : moz-landing-system : lando
There functions won't change any internal variables, so they should be marked as const.
Differential Revision: https://phabricator.services.mozilla.com/D29590
--HG--
extra : moz-landing-system : lando
In D25705, I added a new arenaId member to the js::BaseAllocPolicy. This
increased the size of everything that uses a JS AllocPolicy, which is a
lot.
This change follows suit from earlier work, which is to make everything
allocation-related have an "arena" version and a "default" version that
uses the arena version with the implied default arena.
StringBuffer is then changed to use this new functionity to define its
own alloc policy that uses the new StringBufferArena.
Differential Revision: https://phabricator.services.mozilla.com/D29685
--HG--
extra : moz-landing-system : lando
I'm still wondering why is bing.com doing this but oh well. This should address
the regression and probably even improve it.
I don't think these documents are observable from content (at least I haven't
found how) so this should be safe. Let me know if you want me to just wrap the
whole stylesheet in an `@media (width > 0) and (height > 0)` rule or such.
Differential Revision: https://phabricator.services.mozilla.com/D29640
--HG--
extra : moz-landing-system : lando
The android harness had accumulated some unnecessary and contradictory option handling.
Today, libraries must be extracted from an apk: options.localAPK is required, and
options.localLibs is unused. Cleaning up this code also removes some fennec-isms.
Additionally, this patch relaxes the requirement to find package-name.txt in the apk,
clearing the way for running against a geckoview apk (I may generalize that further
in a follow-up, but not sure what is needed yet).
Differential Revision: https://phabricator.services.mozilla.com/D29709
--HG--
extra : moz-landing-system : lando
This commit exports livemarks before syncing for the first time, to
avoid losing livemarks that Sync may have resurrected. As of v0.2.4,
Dogear treats livemarks as non-syncable, and deletes them on both
sides.
This also bumps the mirror schema version, to trigger a first sync.
Differential Revision: https://phabricator.services.mozilla.com/D28543
--HG--
extra : moz-landing-system : lando
CompositorD3D11's implementation of `GetWindowRenderTarget` would return a
`nullptr` if we were not presently recording a profile with screenshots. Now,
CompositorD3D11 correctly will return a window render target when it has been
asked to by the `LayerManagerComposite` via `Compositor::RequestRecordFrames`.
Differential Revision: https://phabricator.services.mozilla.com/D29369
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
The button (using a div) did not have any hover state before this patch.
While the CSS tried to control the stroke color, the SVG was not set up
for this – also fixed in this bug to correctly use the theme colors.
Differential Revision: https://phabricator.services.mozilla.com/D24742
--HG--
extra : moz-landing-system : lando
This patch replaces the quick-n-dirty implementation of -force-launcher with
one that makes LauncherRegistryInfo aware of that state, thus correctly setting
the affected registry values.
Differential Revision: https://phabricator.services.mozilla.com/D29545
--HG--
extra : moz-landing-system : lando
* New installs should always have launcher process telemetry enabled by default
(since it is opt-out telemetry).
* Upgrades do a reset of the force-disabled launcher state, as that state might
have been set by SHIELD but is no longer desired in 68.
* We add the `|Telemetry` registry value to the list of values to be removed at
uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D29544
--HG--
extra : moz-landing-system : lando
