By adding a small blank space to the end of the text, we can make the animation look faster. Also, the issues with the animation wouldn't be noticeable in that space.
MozReview-Commit-ID: H67YL6WZEd1
--HG--
extra : rebase_source : 2555fb0b40a9c83205537a969fe905f7f083f70a
extra : amend_source : 7a2deeb18c3e8dcc93fce1bca4be9efb8585e685
This bug handles abnormal client shut down case and Tab move between different windows.
Abnormal client shut down case, WebRenderBridgeParent does not receive IPC messages that are sent during WebRenderLayerManager and WebRenderBridgeChild destruction. In this case, webrender keys except keys of external images are not removed from webrender. Abnormal shut down could happen when content process was crashed or content process was killed by ContentParent if shutdown takes too long time.
In the tab move case, the WebRenderBridgeParent will need to be re-bound to a different CompositorBridgeParent and webrender, and so will need to clear all its related keys from the old webrender. This will happen in a future patch.
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
The problem is if we found a cache hit, then we could go through
ValidateRequestWithNewChannel to validate the cache.
Then if the CSP check fail(asyncOpen2() will fail), then the
imgRequestProxy will remain there, and cause the timeout.
I run into problem when running mochitest
browser/base/content/test/general/browser_aboutHome.js in non-e10s mode.
In the beginning, browser.xul will load defaultFavicon.png, will create
an image cache there.
Next time when the test starts to run, when it loads about:home, then it
will try to load defaultFavicon.png, it will found an image cache hit
(loaded previously by browser.xul), and call
ValidateRequestWithNewChannel there, however the asyncOpen2 call failed,
and the imgRequestProxy is added to the loadGroup of about:home, and
never be notified until timeout.
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
