We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
The only protocol that can't be created off the main thread at the moment is
moz-extension, and that can be handled at a later time.
Differential Revision: https://phabricator.services.mozilla.com/D30713
--HG--
extra : moz-landing-system : lando
Just trying to make it slightly nicer. Probably should get a function to get the
root target document frame.
Will file a bug for fission since I _suspect_ fission is going to do something
about IntersectionObserver.
Depends on D31149
Differential Revision: https://phabricator.services.mozilla.com/D31150
--HG--
extra : moz-landing-system : lando
There's nothing here that should be mutating us (and if there was we'd be hosed
already given the amount of weak pointers we keep around), so this is nicer.
Depends on D31148
Differential Revision: https://phabricator.services.mozilla.com/D31149
--HG--
extra : moz-landing-system : lando
Should've no behavior change given the spec issue, but it should read nicer.
Differential Revision: https://phabricator.services.mozilla.com/D31148
--HG--
extra : moz-landing-system : lando
Unencrypted samples can carry init data and thus we should set the init data
type regardless of if the sample itself is encrypted (otherwise the init data
info is incomplete for unencrypted samples).
Depends on D32751
Differential Revision: https://phabricator.services.mozilla.com/D32752
--HG--
extra : moz-landing-system : lando
Add another test case for the mp4 key rotation (pssh in fragments) test. In this
case, the test file has a clear (unencrypted) lead. This test seeks to ensure we
don't regress surfacing of init info even if we encounter it for fragments that
start with unencrypted samples.
Add a further check to the key rotation test to ensure that the initDataType is
being surfaced correctly on the encrypted event.
Media files created with shaka packager via:
```
packager-win.exe
in=bipbop.mp4,stream=audio,out=bipbop-clearkey-keyrotation-clear-lead-audio.mp4
in=bipbop.mp4,stream=video,out=bipbop-clearkey-keyrotation-clear-lead-video.mp4
--enable_raw_key_encryption --keys
label=:key_id=00112233445566778899AABBCCDDEEFF:key=00112233445566778899AABBCCDDEEFF
--crypto_period_duration 5 --fragment_duration 5 --clear_lead 3
```
Note that the way shaka packager handles key rotation in this case is just to
left shift the key id and the key. In this case, where crypto_period_duration ==
fragment_duration, a left shift of 1 will take place each time the keys rotate.
This happens once in the test file leaving us with 2 key ids + keys.
Depends on D32750
Differential Revision: https://phabricator.services.mozilla.com/D32751
--HG--
extra : moz-landing-system : lando
test_eme_pssh_in_moof tests if our key rotation works correctly. It currently
does so by using a single video with an audio and video track. This patch
refactors the test so that it does the same thing (all going well), but in a
more extensible way.
The changes in this patch seek to lean more heavily on test harness
functionality in manifest.js and eme.js where possible. This cuts down on some
boilerplate, but means we have to make some concessions in a more verbose
expression of our test media list so the eme.js functions work with it.
Differential Revision: https://phabricator.services.mozilla.com/D32750
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
This async/await-ifies the test to put checks in logical order.
It also, as a drive-by, adds `v.token = token` since this is a cue to the test
framework in manifest.js to mozDumpDebugInfo() on the right element after
timeout of a token.
Differential Revision: https://phabricator.services.mozilla.com/D32114
--HG--
extra : moz-landing-system : lando
This assert can be racy if the following sequence happens:
SetPlaying() -- watch manager schedules SendData()
Stop() -- unwatches mPlaying, resets mStartTime
SendData() -- fails the assert
SendData handles the case where mStartTime is unset at runtime already through the mData check, further making this assert unnecessary.
Depends on D32112
Differential Revision: https://phabricator.services.mozilla.com/D32113
--HG--
extra : moz-landing-system : lando
The following sequence in DecodedStream could lead to a stall for a captured
media element:
- MediaDecoder decodes some data, DecodedStream sends it out
- MediaDecoder pauses for buffering, DecodedStream sees SetPlaying(false)
- MediaDecoder decodes until the end, DecodedStream doesn't send since it's
not playing
- MediaDecoder starts playing again, DecodedStream sees SetPlaying(true)
At the last step above, SetPlaying(true) doesn't trigger SendData() so no data
is sent out. Since all data has already been decoded, nothing can trigger
SendData() anymore. This patch fixes this by calling SendData() on SetPlaying().
Depends on D32111
Differential Revision: https://phabricator.services.mozilla.com/D32112
--HG--
extra : moz-landing-system : lando
We used to do that for FragmentOrElement too, but it was removed in D3533. The
explanation is a bit hidden in the revision, but quoting:
> Needed to remove the IN_SHADOW_TREE flag removal from unlinking since it may
> make a ShadowRoot claim not to be a ShadowRoot (nsINode::IsShadowRoot() would
> return false).
>
> In practice it was there because there was code that assumed that
> IsInShadowTree() -> GetContainingShadow() != nullptr
>
> But that stopped holding a while ago, and callers have been adjusted in the
> meantime to not assume that, so it should be fine to not remove the flag now.
We also unbind the Shadow tree on unlink now, which didn't use to happen.
This makes CharacterData consistent with FragmentOrElement.
Differential Revision: https://phabricator.services.mozilla.com/D32627
--HG--
extra : moz-landing-system : lando
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--HG--
extra : moz-landing-system : lando
These usecases are almost the same as the geometry property stuff. It'd
be better to use `GetPrimaryFrame()->Style()` consistently rather than
using `GetComputedStyleNoFlush()` here.
Differential Revision: https://phabricator.services.mozilla.com/D32613
--HG--
extra : moz-landing-system : lando
Resolving length for inner <svg> is exactly the same as other ordinary
element. We should not pass the context to `GetAnimValue()`, otherwise
font-size will be obtained from the enclosing viewport of the inner
<svg> rather than the inner <svg> itself.
Differential Revision: https://phabricator.services.mozilla.com/D32657
--HG--
extra : moz-landing-system : lando
The test assumes "en" is always an accepted language, it's not correct.
This assumption isn't what is being tested here anyway.
We should set language preference at the beginning before testing to avoid
irrelevant failure.
Differential Revision: https://phabricator.services.mozilla.com/D32628
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando