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
There's no good reason why we should let unnamed threads through this interface.
Differential Revision: https://phabricator.services.mozilla.com/D29672
--HG--
extra : moz-landing-system : lando
We were incorrectly not performing an EnsureSubscribed for the origin
process which a BrowsingContext came from. Normally this would mean that
the BrowsingContext could die in the parent process before the
WindowGlobalParent listener arrived, but that didn't generally happen
due to the low likelihood of a CC occuring between the two messages.
It's likely that this crash was caused by people on lower-end hardware
triggering a print. This would be a longer-running operation in the
content process between the first and second message than usual. On
systems with memory pressure, there would be a higher chance of a CC
occuring between the messages, which would then cause this crash.
This patch correctly connects the origin ContentParent to the
BrowsingContextGroup, which will prevent the CC from destroying our
objects.
In the future, it may be desirable to ensure that this doesn't happen
more reliably by using a ContentParent-local table for looking up
BrowsingContext IDs sent over IPC. This would prevent our current
dependency on the weak pointer behaviour of the current global ID cache.
Unfortunately, this patch adds no tests, and I'm not aware of a good way
to test this edge case to confirm it has been fixed. I believe that this
patch should fix the issue I mention, however.
Differential Revision: https://phabricator.services.mozilla.com/D29563
--HG--
extra : moz-landing-system : lando
The failures when running the app update tests during TV runs print an activity stream error to the console and this will at the least eliminate it as a cause for the failure and possibly will prevent these tests from failing during TV runs.
Differential Revision: https://phabricator.services.mozilla.com/D29612
--HG--
extra : moz-landing-system : lando
This issue was caused by the updating of the caret position after the paste occurs firing an `updateposition` event resulting in an `GeckoView:ShowSelectionAction` message to reposition context menu without any attempt to close the context menu. The solution is to hide the context menu before the repositioning of the caret occurs such that the `updateposition` event doesn't trigger a redisplay.
I tried several versions of this trying to trigger the menu close from inside `GeckoViewSelectionActionDelegate`, including making the call to `docShell.doCommand("cmd_paste");` asynchronous and firing `ACTION_HIDE` before firing `ACTION_PASTE`, but the result is always the same - one of the events is processed before the other and so the second event is rejected as a stale response.
Therefore we are firing the `pagehide` from inside the code that performs the paste. This has to be done before the paste occurs otherwise the `updateposition` event is fired before the page hide event and the context menu redisplays before being hidden.
Differential Revision: https://phabricator.services.mozilla.com/D29665
--HG--
extra : moz-landing-system : lando
Byron Campen [:bwc]
alwu
Shane Caraveo
Chris Martin
Jim Porter
Mike Conley
Emilio Cobos Álvarez
Robin Templeton
Brian Grinstead
Jason Laster
Matthew Noorenberghe
Geoff Brown
Bogdan Tara
Lina Cambridge
Nazım Can Altınova
Markus Stange
Edouard Oger
Nika Layzell
Barret Rennie
Josh Matthews
Botond Ballo
Harald Kirschner
Andrea Marchesini
Mathieu Leplatre
Aaron Klotz
Nathan Froyd
Robert Strong
yulia
Michael Kaply
Bastien Abadie
Emily Toop
Gian-Carlo Pascutto
Ehsan Akhgari
Valentin Gosu