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
We test the expected behavior base on the pref,
"security.data_uri.unique_opaque_origin".
We run the legacy test when the pref is off, however if the pref is on,
we run the new behavior, loading an iframe with X-FRAME-OPTIONS in a
data: URI should be blocked.
Move the data URI in 'if_no_scripts' and 'if_scripts' to seperate files.
Also remove the test 'if_19', as it seems redundant, it tests the same
thing with the iframe 'if_scripts', and it also lacks of 'allow-scripts'
in its sandbox flag.
A mochitest browser test for image blocking.
We query the blocking status by reading imageBlockingStatus.
See nsImageLoadingContent.cpp for the logic of blocking image.
In this test we verified the following behavior:
1. image is loaded.
2. image is blocked.
3. mCurrentRequest doesn't have size yet, so it should be replaced.
4. mCurrentRequest already got size, the following request should be a
pendingRequest.
Use a boolean to prevent calling SetBlockedRequest asynchronously.
Also use the same boolean to prevent some evil code reenters LoadImage.
Then we should redesign the correct bahavior in those follow-up bugs,
Bug 1353685 - Should ServiceWorker call SetBlockedRequest
Bug 1353683 - consider calling SetBlockedRequest in nsCORSListenerProxy::UpdateChannel
Bug 1371237 - consider calling SetBlockedRequest in nsContentSecurityManager::CheckChannel
As a follow-up from bug 1206961, we will remove calling CanLoadImage in
this bug. Also in the case of CSP check failed, we will call
SetBlockedRequest in those cases.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1267075#c30 for the
analysis between the old and new setup.
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
These are no longer needed as we have the data we were looking for.
MozReview-Commit-ID: 3WlPng3mAwt
--HG--
extra : rebase_source : 73a390f85f5c0894d53a5e8ee10b19278af58282
extra : amend_source : 6a2b9ff4191715d0ac6e43f92af1e64c59123ac6
When styling with the Servo backend, we should also use the Servo backend to
determine if a property is animatable or not. However, if we do this,
Servo_Property_IsAnimatable will start returning true for the 'display' property
once we mark that as animatable in Servo (for SMIL).
Even if we later fail to actually animate 'display' (due checks added to Servo
in the next patch) we still need to treat 'display' as un-animatable in
KeyframeUtils so that we don't *read* the 'display' property of Keyframe objects
passed to the Animations API, since that is observable.
This patch makes us consult Servo_Property_IsAnimatable when using the Servo
backend and also explicitly treat the 'display' property as not animatable.
MozReview-Commit-ID: 1JllbeJisAS
--HG--
extra : rebase_source : d73b7d9ee0da03bfed68e574b67e10b342c1868d
The intermittent failure appears to have been due to mOriginsHavingData
only being updated when the db thread flushes. The db thread has a
hard-coded 5 second flush interval. It's likely that e10s startup was
previously so slow that we were assured of having a flush happen by the
time our fresh process created its parent actor.
We correct this by reliably ensuring a flush before spinning up the
process to check preload state. We also ensure a flush at the start of
the test for our check that there was no preload in the initial cases.
We were actually more vulnerable in that case, I believe, but as a
browser chrome test, there were no other tests that would have used
content localStorage.
We additionally ensure that the content process has received and
populated mOriginsHavingData by having the tab opening process wait for
about:blank to load in the process before actually opening our origin.
Prior to this change we were depending on orderings that aren't
guaranteed.
--HG--
extra : rebase_source : 92d3c675cee82ffe8b562e83860601e0c6dc1a9b
Bug 1345990 introduced a "forceNewProcess" argument in
BrowserTestUtils.openNewForegroundTab. By switching to this we can
stop bloating the process count pref to try and produce equivalent
results. To minimize test churn and because it doesn't really hurt to
double-check, the code that asserts that our tabs are each in different
processes and related book-keeping infrastructure have been left intact.
We also set a preference to disable preallocated processes in the interest
of maximizing test consistency and minimizing breakage. It's conceivable
that a preallocated process might end up creating its StorageDBParent
actor prior to when we want, breaking things. By ensuring the process
isn't created until we want it, we avoid a lot of brittleness.
--HG--
extra : rebase_source : 5736f7b2d06b720cefbe82eb6052e71b9fc14f23
Per spec [1], date/time inputs fall into this category:
"For input elements without a defined input activation behavior, but to which
these events apply, and for which the user interface involves an explicit
commit action but no intermediate manipulation, then any time the user commits
a change to the element's value, the user agent must queue a task to first fire
an event named input at the input element, with the bubbles attribute
initialized to true, and then fire an event named change at the input element,
with the bubbles attribute initialized to true."
So, we fire input/change events when:
- User selects a date/time from the picker
- User changes the value using up/down keys in a already complete date/time
value
- User changes the value using the number keyboard in a already complete
date/time value
- User clears the value (using reset button or using backspace)
MozReview-Commit-ID: E7Jc5qMKZj4
--HG--
extra : rebase_source : 01d4ddbf97d7cef626491946e008a88db4641258
Specifically,
* replace a few Get+Put with LookupForAdd
* remove an unnecessary Get before Remove, and
* replace an Get+Remove with LookupRemoveIf
MozReview-Commit-ID: HBeIK9CZC00
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This will give enough information (for now) for GetMediaCache to decide whether
to use the (one global shared) file-backed MediaCache, or a discrete memory-
backed MediaCache.
(Note that GetMediaCache doesn't use this length yet in this patch.)
MozReview-Commit-ID: 5B2E3sIsc4k
--HG--
extra : rebase_source : 940e782665bf2c3640bbe7389fca02ea7c1482cd
This is the new recommended way to create&initialize the file-backed
MediaCache.
In future patches, this will also allow the creation of memory-backed
MediaCache objects.
MozReview-Commit-ID: 6RUlNW2eBPP
--HG--
extra : rebase_source : 0b3e6fae71207076812b5cb9172d4497d3e68ea2
MediaCacheFlusher constructs itself when needed by the first MediaCache, and
destroys itself when the last MediaCache unregisters itself.
Some MediaCache member functions had to be made non-static, so they could be
called for each instance.
MozReview-Commit-ID: 5Dh9mEKbZHg
--HG--
extra : rebase_source : 1570e30787ba486f9436b4b05aa3cfa0329d1ee7
There is no spacing mode any more, so rename this function.
MozReview-Commit-ID: 9DIqKmQnuJo
--HG--
extra : rebase_source : 3600be87a699a1a5fe237f8ed75baf03f0b5ae84
To prevent addons or other code to rapidly create and destroy content processes
under various conditions, we let the preallocated process manager to reuse short
lived content processes.
Tim Huang
John Dai
Sebastian Hengst
Andrea Marchesini
Bill McCloskey
Yoshi Huang
Manish Goregaokar
Gerald Squelart
Ben Kelly
domfarolino@gmail.com
Wes Kocher
Ryan Hunt
Michael Layzell
Chih-Yi Leu
Andrew Osmond
Mats Palmgren
Nicolas B. Pierron
Carsten "Tomcat" Book
Brian Birtles
Robert Longson
JerryShih
Andrew Sutherland
Olli Pettay
Eden Chuang
Jessica Jong
Kris Maglione
Matt Woodrow
Samuel Vargas
Joanmarie Diggs
Boris Zbarsky
Peter Van der Beken
Cameron McCormack
Henri Sivonen
Boris Chiou
Xidorn Quan
Daosheng Mu
Lee Salzman
Gabor Krizsanits
Marco Castelluccio