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
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
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
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
Replace the MacSandboxType_Plugin sandbox type with MacSandboxType_Flash and MacSandboxType_GMP so that there is a 1:1 association between MacSandboxType values and sandbox policies.
Remove the MacSandboxPluginType enum. Instead of having different MacSandboxPluginTypes, we will just have MacSandboxType_GMP. We only use GMP for two plugin types, Widevine and OpenH264, and they only differ in that Widevine requires accss to the WindowServer.
Remove the MacSandboxPluginInfo struct and move the two needed fields pluginPath and pluginBinaryPath to MacSandboxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D29585
--HG--
extra : moz-landing-system : lando
This also adds an isTopFrame attribute to the FrameCrashedEvent binding, which
returns true if the frame that crashed was the top-most one.
Differential Revision: https://phabricator.services.mozilla.com/D29236
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
float(INT32_MAX); gets compiled into 2.14748365E+9 using clang, which is slightly bigger than INT32_MAX, as such 2.14748365E+9 <= INT32_MAX will return true (as INT32_MAX gets converted to a float)
Differential Revision: https://phabricator.services.mozilla.com/D29464
--HG--
extra : moz-landing-system : lando
Need to write a test for this. Also, as a matter of preventive measure, null out
mOwner when it dies.
That may matter in the case where the controller dies while the observer is
getting notified. In that case, somebody still keeps a reference to the
controller. Right now is fine because nothing will touch it again (the
destructor doesn't), but that's not great, and it's better to just clear the
pointer.
Differential Revision: https://phabricator.services.mozilla.com/D29395
--HG--
extra : moz-landing-system : lando
We want to start exposing the storage manager (`navigator.storage.persist`) for GeckoView enabled apps, but continue not exposing it in Fennec. To enable this a new entry type for Fennec only (different from generic Android) is added to allow us to continue to exclude Fennec from the tests while enabling the tests for other Android builds.
Differential Revision: https://phabricator.services.mozilla.com/D29226
--HG--
extra : moz-landing-system : lando
This patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
In this part, we pass along the navigation type (and index for when using the
dropdown on the back/forward buttons). This allows us to check if there's a
top-level load "between" the start and end pages.
The patch might look a bit strange, since we're passing the navigation
operation to two places from RemoteWebNavigation.js (the normal message passing
that existed before this patch and the HangMonitor channel in this patch). This
is primarily to make it easier to stop passing the navigation info along the
HangMonitor channel once session history is uplifted into the parent process.
At that point, the check for whether there's a top-level load could happen in
TabParent (I think).
Differential Revision: https://phabricator.services.mozilla.com/D23090
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
These are added in start, and we get into unexpected state if they notify us
after Stop() (when MediaEncoder shuts down and internally removes the tracks
it is encoding) but before Shutdown() when we remove the listeners. This is not
symmetrical. The proper thing to do is to remove these listeners in Stop() as
well.
Depends on D29080
Differential Revision: https://phabricator.services.mozilla.com/D29081
--HG--
extra : moz-landing-system : lando
The mp4 demuxer already does this, so have the WebM case follow suit. This
avoids asserts with creating 0 size shmems in the case where the demuxer is
being used with the remote data decoder.
Differential Revision: https://phabricator.services.mozilla.com/D25846
--HG--
extra : moz-landing-system : lando
This removes all references to application capture except from MediaSourceEnum.
That was left in place so as to not change the enumerated values used
for WEBRTC_GET_USER_MEDIA_TYPE telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D28089
--HG--
extra : moz-landing-system : lando
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando