This patch removes the responsibility of js-facing MediaStreamTracks from the
MediaDecoder stack, and moves the machinery for setting up DecodedStream to
higher order functions like state mirroring and watchables.
OutputStreamManager is completely gone, since it was designed to manage
MediaStreamTracks across multiple output streams for a single decoder,
on main thread. HTMLMediaElement took over its task in the previous patch.
The MediaDecoderStateMachine now has three control points for capturing:
- mOutputCaptured, which, if true, will capture all decoded data into
mOutputTracks. If this is set, but mOutputTracks is empty, we are still
waiting for tracks, and DecodedStream will not play any data. When tracks are
set, a new DecodedStream is created that will play data through
SourceMediaTracks piped into mOutputTracks.
- mOutputTracks, which is the set of tracks data is captured into, for
forwarding to all the output tracks the media element is managing. This set of
tracks is managed by the MediaDecoder owner, and must contain one audio track
if the decoder is decoding audio, and one video track if the decoder is
decoding video. It may be empty since output can be captured before metadata
is loaded, or playback has ended.
- mOutputPrincipal, which is the principal of the decoded data. All data sent
into SourceMediaTracks is tagged with this principal.
Differential Revision: https://phabricator.services.mozilla.com/D52042
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
HTMLMediaElement avoid creating new tracks in MetadataLoaded when it has already
created some, so there should be no side effect to this patch.
Differential Revision: https://phabricator.services.mozilla.com/D52037
--HG--
extra : moz-landing-system : lando
On an https: page it's more important to use the login was from the same hostPort than to use an https: login from a different subdomain.
This fixes autocomplete to show "From this website" and also fixes autofill in the event that there was a duplicate username+password combo saved on an different https: subdomain while previously saving that combo on the http: version of the same hostPort.
Differential Revision: https://phabricator.services.mozilla.com/D52802
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
This patch makes use of the new application section in the perfherder data to provide the browser name and version being tested.
Differential Revision: https://phabricator.services.mozilla.com/D52565
--HG--
extra : moz-landing-system : lando
Extend timeout to ease intermittent at this moment. File Bug 1595848 for follow-up
Differential Revision: https://phabricator.services.mozilla.com/D52714
--HG--
extra : moz-landing-system : lando
The addon details returned from the AMO API endpoint for webextensions static themes is type "statictheme",
but for an installed WebExtension static theme we expect addon.type to be "theme", and so
AbuseReporter.queryAMOAddonDetails should normalize the type received to ensure it matches what
Firefox expects.
This fix is needed to ensure that reporting a "not installed" theme from AMO works as expected
(see https://github.com/mozilla/addons-frontend/issues/8762#issuecomment-553430081).
Differential Revision: https://phabricator.services.mozilla.com/D52853
--HG--
extra : moz-landing-system : lando
id-ecPublicKey is defined as the OID {iso(1) member-body(2) us(840)
ansi-x962(10045) keyType(2) ecPublicKey(1)}, and is the NSS default, so
remove the override code from CryptoKey.cpp that forced it to the legacy
id-ecDH code.
Differential Revision: https://phabricator.services.mozilla.com/D52570
--HG--
extra : moz-landing-system : lando
Bug 1034856 added support for DH algorithms to WebCrypto, however the final
specification did not choose to include them, making Firefox the only browser
with support.
Bug 1539578 added telemetry to show usage, and it is extremely low (not
appearing on the graphs), which could be expected as Firefox is the only
supporting browser.
Since DH is an ongoing maintenance burden -- and overall cryptanalysis of DH
is progressing -- let's remove it.
Notice to unship went to dev-platform on 29 March 2019 with no objections. [0]
[0] https://groups.google.com/d/msg/mozilla.dev.platform/Ut3-eQmUdWg/O9w1et1aBgAJ
Differential Revision: https://phabricator.services.mozilla.com/D50865
--HG--
extra : moz-landing-system : lando
This bug disables vismet for browsertime until the png/artifact issues are resolved.
Differential Revision: https://phabricator.services.mozilla.com/D52837
--HG--
extra : moz-landing-system : lando
After examining bug 1591047, I believe we should have added an Int32 type instead of changing the semantics of ArgType_General to be Int32. The reason is that the existing code assumes ArgType_General is pointer sized, and changing this is scary for all the existing uses. (e.g. simulator, MacroAssembler::appendSignatureType)
* Adds ArgType_Int32
* Changes ArgType_General -> ArgType_Int32, ArgType_Pointer -> ArgType_General for ABIFunctionTypes introduced in bug 1591047 (which are only used for Wasm instance calls).
* ToMirType(ArgType_General) -> MIRType::Pointer (should only affect wasm)
* ToMirType(ArgType_Int32) -> MIRType::Int32 (should only affect wasm)
Differential Revision: https://phabricator.services.mozilla.com/D52177
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
The test that is timing out with these patches does something relatively simple:
await TestUtils.waitForCondition(async function() {
let color = await ContentTask.spawn(browserWindow, async function() {
/* Do stuff... */
});
return color == something;
});
await closeWindow(browserWindow);
Turns out that this can intermittently leak the window due to waitForCondition
using setInterval. setInterval can schedule multiple tasks while awaiting for
the inner ContentTask.
What this means, is that we may still have a ContentTask awaiting us when we get
to close the window. Closing the window makes the ContentTask not finish, and
thus we leak a promise keeping alive the window in gPromises:
https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/testing/mochitest/BrowserTestUtils/ContentTask.jsm#24
Which means that we keep alive the window all the way until shutdown.
Fix it by ensuring that we only run one task at a time.
Differential Revision: https://phabricator.services.mozilla.com/D52833
--HG--
extra : moz-landing-system : lando
We want the profiler UI to be able to know if the data can be used for
reconstructing the event delays, since it measures something different
from the old 16ms event injection.
Differential Revision: https://phabricator.services.mozilla.com/D52534
--HG--
extra : moz-landing-system : lando
This gives developers the ability to request analysis from the Pernosco
service. When this flag is set, Pernosco will examine the push for relevant
failures, analyze them and then send a link to the generated report.
Previously developers needed to request access to a whitelist whereupon all
their try pushes were analyzed. Developers currently on this whitelist who
would like to opt-out can run |mach try --no-persnosco| to do so.
Differential Revision: https://phabricator.services.mozilla.com/D52419
--HG--
extra : moz-landing-system : lando
Stereo output is what the immense majority of mobile and desktop users have.
Differential Revision: https://phabricator.services.mozilla.com/D52693
--HG--
extra : moz-landing-system : lando
Depends on D52560
- Adds a test to check that the steps for [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944) no longer cause an issue.
- Introduces a new `updateDeclaration()` helper in `devtools/client/inspector/rules/test/shared.js` to simplify updating property names and values in one step.
- Updates `toggleDeclaration()` to remove unused `inspector` parameter; updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D52561
--HG--
extra : moz-landing-system : lando
The fix for [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) created a situation in the [`Rule.onDeclarationsChanged()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/client/inspector/rules/models/rule.js#869-887) whereby the `isUsed` state of client-side declarations was made to point to a fixed `isUsed` state received from the server, thus losing sync with the latest state of the `StyleRuleActor`. Until another "declarations-update" event was fired from the `StyleRuleActor`, the rule's declarations' `isUsed` flag would point to the state with which they were overwritten on the last event handler call.
As a reminder, the root cause of [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) was the inability force a "refresh" of the `StyleRuleFront` so it picked-up the latest `isUsed` state for its declarations when they depend on other declarations from other rules (ex: `justify-content: center` depends on `display:flex`). Therefore, the "declarations-updated" event was introduced with a payload of changed declarations to overwrite the client-side ones. It was convoluted, but it worked.
However, while investigating the cause of this newer bug [Bug 1593944](https://bugzilla.mozilla.org/show_bug.cgi?id=1593944), I discovered an unusual but perhaps expected side-effect: when dispatching an event over the protocol with a payload of the `StyleRuleActor`, its corresponding `StyleRuleFront` on the client would "refresh" automatically (meaning that, looking up state on the previous front reference would point to the latest state from the actor) . The client doesn't even need to use this payload to replace its previous front reference. Surprisingly, the client doesn't even need to explicitly listen to the event which carries the `StyleRuleActor`/`StyleRuleFront` reference. So long as a previous reference of the front exists on the client, it will point to the updated state of the actor. I haven't been able to identify whether this is a known and expected behavior, so I'm pinging @jdescottes and @ochameau to weigh in on the validity of these findings.
Relying on this behavior, the fix for both [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) and [Bug 1557689](https://bugzilla.mozilla.org/show_bug.cgi?id=1557689) involves simply emitting an event, "rule-updated", with the `StyleRuleActor` instance as payload whenever its internal state changes meaningfully so the corresponding front updates. The client will pick-up the latest `isUsed` state of declarations from its reference to the `StyleRuleFront`.
---
Another way to check this behavior and hypothesis is to do the following:
- In [`StyleRuleActor.setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1704) replace `return this` with `return null`; (this will no longer return the `StyleRuleActor` over the protocol; it's not explicitly used on the client anyway).
- In the spec, replace the [`setRuleText()`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/shared/specs/styles.js#222) return value with `RetVal("nullable:domstylerule")` so the protocol doesn't throw an error when getting the `null` from the actor.
- Make a build.
- Then, open the Inspector -> Rules View and change the value of a valid declaration, say: `display: block`, to something invalid, like `display: booo`. Notice that the declaration is no longer marked invalid with a warning sign. That's because the declaration's [`isValid`](https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/devtools/server/actors/styles.js#1447) flag is set on the actor but it no longer syncs with the client which uses the corresponding front to render the declaration after the change. Not returning the `StyleRuleActor` over the protocol breaks this sync actor-front sync.
Differential Revision: https://phabricator.services.mozilla.com/D52560
--HG--
extra : moz-landing-system : lando
