These rules are set explicitly to allow the two views to be displayed next to
each other briefly when the slide-in transition starts.
This patch also applies the last remaining photon styles to the temporary panel,
which is used by the new Library widget as well.
MozReview-Commit-ID: 45aYzVHwRYv
--HG--
extra : rebase_source : 0bf4fc4effc9de9e431ee50dfcf5fc7206e252cf
Something changed in the timing and we're getting more candidate pairs
in the test now. I changed the test to only compare most of the
details when the pair is in state succeeded.
MozReview-Commit-ID: FaR00eZPJmI
--HG--
extra : rebase_source : 9e29f7604f6ae198cbaf792171db265612a574a6
Cue whose start times are less than or equal to the current playback position and
whose end times are greater than the current playback position.
MozReview-Commit-ID: 2I5lgjUUtgB
--HG--
extra : rebase_source : 5396f932da54cf175fe330f0caf85472ac9f7e42
This patch adds a test case in the same file of part 3 that to check that does
fingerprinting resistance work correctly for workers when 'privacy.resistFingerprinting'
is true.
MozReview-Commit-ID: FoceQTGg127
--HG--
extra : rebase_source : ead0979a5b7d2f34804ceecf004155a0100fa064
This test case will open a content tab and access performance API in that
tab to check whether or not performance APIs are correctly spoofed.
MozReview-Commit-ID: KdG6xzQFmv6
--HG--
extra : rebase_source : d064d5a90d525190402107c22bac9ed2dfd4c085
This patch is going to neutralize the threat of fingerprinting of performance API
by spoofing the value of performance timing into 0, making getEntries* functions
always returns an empty list and making mark() and measure() into NOP methods.
In addition, this patch changes nsContentUtils::ShouldResistFingerprinting() to
allow it can be called in both main thread and worker threads.
MozReview-Commit-ID: C8Jt7KEMe5e
--HG--
extra : rebase_source : 85cbf66881c868ca5109022ffd4af81e3ab0a049
This is a rebase of #17325 with `[replace]` entries removed, a bunch more dependencies updated, and some more compile fixes. Original work by @Eijebong, thanks a lot!
Source-Repo: https://github.com/servo/servo
Source-Revision: 66c130d55aa0d7af1104c00e93a5bf950f23a383
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 323361580a540d8b296f6f7d77f20d46cbdc5c73
Now that MediaCache doesn't use the content length to decide which block cache
to use, and can know it's the file-backed MediaCache (to reset the pointer,
and for telemetry purposes), we don't need to store mContentLength anymore.
MozReview-Commit-ID: KjxarKFe9WK
--HG--
extra : rebase_source : e2cb397c6d5e37a8390479f4245255ef52265483
MemoryBlockCache won't allow initializing, or growing an existing buffer,
above the limit (min of 'media.memory_caches_combined_limit_kb' or
sysmem*'media.memory_caches_combined_limit_pc_sysmem'/100).
MozReview-Commit-ID: 6MkwFp2eeth
--HG--
extra : rebase_source : 17345f6fe9f00fddfbef87090665afccaabb2cf5
This allows a fallback to the file-backed MediaCache, if a MemoryBlockCache
could not be created and initialized (which may happen in the next patch,
where MemoryBlockCache will take care of not using more than
MediaMemoryCachesCombinedLimit).
MediaCache::Init() is not needed anymore, as its only work was to initialize
its block cache.
MozReview-Commit-ID: ItAdOPuxEvt
--HG--
extra : rebase_source : 08461d61b8d738edb8c2088bca4e33213b8ae4e1
This saves from destruction&re-construction efforts, makes the flushing less
prone to first-initialization failures.
And it will allow moving the choice of block cache outside of MediaCache::Init.
MozReview-Commit-ID: 8vSunM3rRkL
--HG--
extra : rebase_source : d244c9ff0cb34f9b2171e5f5848501cc1d71d2bc
This will be useful to let the MediaCache flush its block cache without having
to restart from scratch (and risk failing).
MozReview-Commit-ID: At3mxH9jb9m
--HG--
extra : rebase_source : b5ac513c6d6d100c8eb41220991388470c0b1a5e
MediaCacheStreams have owning shared pointers to their MediaCache, and
a MediaCache owns itself while an update is in flight.
A non-owning pointer `gMediaCache` is only used by GetMediaCache and
~MediaCache to manage the one file-backed MediaCache.
MozReview-Commit-ID: AQHuXWGrKt6
--HG--
extra : rebase_source : f256e20080b8701f87418209aa42c5a0fe3f5239
The only external use of Close was always followed by an implicit destruction
(by resetting the RefPtr), so we don't need to expose it, and it can be done
from the destructor.
FileBlockCache keeps its Close() function for internal use.
Also, FileBlockCache::mIsOpen is redundant, as it's true iff mThread is not
null.
MozReview-Commit-ID: LV7YVrwJvGG
--HG--
extra : rebase_source : 23decadf249b9e63190b3e19d81edc4a090afcef
Don't go over the lowest of 'media.memory_caches_combined_limit_kb'
(kilobytes) or 'media.memory_caches_combined_limit_pc_sysmem' (percents of
system memory).
Added more logging around creation/destruction of MediaCaches.
MozReview-Commit-ID: Cdz4ycyn1RR
--HG--
extra : rebase_source : 63168234f186c3ef9c0289a189a647d67d8526a4
No errors are expected to happen in MemoryBlockCache (except a few
'InitAllocation', which would still be good to know about), but instead of
taking drastic measures in these cases (i.e., crash), I would prefer to
collect some telemetry first.
MozReview-Commit-ID: 4WdFS34lgzj
--HG--
extra : rebase_source : 5600d0b93d4d438d8cc9cf5a74d9fbf24fe2822e
Memory-backed block cache.
At initialization, allocates memory needed to store the expected content
length.
If MediaCache attempts to write/move beyond the expected size, we grow the
buffer accordingly, as we cannot fully trust HTTP headers. (Future patch will
ensure we put a limit to this growth.)
MozReview-Commit-ID: GHxYMGXYrwI
--HG--
rename : dom/media/MediaBlockCacheBase.h => dom/media/MemoryBlockCache.h
extra : rebase_source : 4fe263006839ba82a77d124f147adf5943cfa651
Because blocks may not necessarily be held in files anymore.
MozReview-Commit-ID: 2GNc7B5w2Jt
--HG--
extra : rebase_source : 4ceda80ca6736b159d8b726cdcfb8d7f74cf8529
This is necessary before we can make FileBlockCache depend on another
ref-counted base in the following patch.
MozReview-Commit-ID: 8bfNwQhY8k0
--HG--
extra : rebase_source : b216d0af3e4b5abb68532f2547597c4f04585a71
The initial telemetry collection was done in NotifyDataLength() because that
was the first point where the length was introduced; but some extra code was
needed to ensure that were collecting the first length.
Now that this initial length is passed directly to Init(), we can report that
number instead.
In the "worst" case, it will actually be a bit more correct about what we
initially wanted to report, i.e., the initial length given by the HTTP
response header; and it's what we really want to know, now that we are using
this number to make a decision about which MediaCache to use.
MozReview-Commit-ID: 11Th8pensZt
--HG--
extra : rebase_source : 97a6d2dcbfad6c9b37819bfe6471baff2ec7e335
