sThread is used in assertions of functions running on sThread. Prior to this
patch, we would null sThread before shutting it down, this meant sThread could
be null while resolving any tasks remaining on that thread. This could lead to
null derefs.
This patch changes the ordering of shutdown so that sThread is not nulled until
after shutdown has taken place.
Differential Revision: https://phabricator.services.mozilla.com/D119333
In addition, the comment seems out-of-date, which was added for running the runnable on the main thread and our code is totally different from that time. So we can remove that as well.
Differential Revision: https://phabricator.services.mozilla.com/D112139
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
- What this patch does:
Send a "download-suspended-by-cache" signal to the media-element paired
with a cloned cache-stream right after the cache-stream is cloned. That
signal help the media-element to decide if it's ready to enter the
HAVE_ENOUGH_DATA state and fire a "canplaythrough" event.
- Why this patch is needed:
It solves a WPT timeout issue. That WPT test waits a "canplaythrough"
event.
- What problem this patch solves is:
This patch addresses the problem mentioned in [1].
Each media-element pairs with a cache-stream downloading the data it
needs. When the data-download of a cache-stream gets suspended, the
media-element paired with the cache-stream should be notified. This
notification is one of the factor to move the ready-state of the
media-element to HAVE_ENOUGH_DATA. However, the media-element paired
with a cloned cache-stream may never receive this notification. And the
worst is that it may never have a chance to download enough data it
needs to move the ready-state to HAVE_ENOUGH_DATA as well at the same
time, in the case mentioned below.
This can happen when a media-element paired with a cloned cache-stream
is created after the cache is full, and all of the cache-streams are
suspended. (Cloned cache-stream is a cache-stream cloned from another
cache-stream that shares the same underlying data with it since their
paired media-elements have the same `src` (of `HTMLMediaElement`)).
"canplaythrough" event is fired when the ready-state is transited to
HAVE_ENOUGH_DATA. As a result, it will never be fired in this case.
In usual case, if the cache-stream gets suspended from non-suspended, it
will send a "download-suspended-by-cache=true" signal to its paired
media-element when running `MediaCache::Update()`. In fact, all other
cache-streams sharing the same underlying data will send this signal at
the same time if necessary. (Later, once the cache-stream is resumed
from suspended to non-suspended it will send a
"download-suspended-by-cache=false" signal to its paired media-element.
All other cache-streams sharing the same underlying data will do the
same if necessary.) The media-element keeps tracking that signal it
receives. After the first-frame of the media-element is loaded, the
ready-state of the media-element will be transited to HAVE_ENOUGH_DATA
by force if the signal is true. (Otherwise, the ready-state will be
inferred by other information.)
When cloning a cache-stream from another one, the cloned cache-stream is
suspended by default. If it's added to a jammed cache that all of the
cache-streams are suspended since the cache is full, then it never has a
chance to fire the "download-suspended-by-cache" signal. Both its
source-stream and itself have no status-change between suspended and
non-suspended, so `MediaCache::Update` is unable to send the signal.
In this case, we should force the media-element paired with the newly
cloned cache-stream transits its ready-state to HAVE_ENOUGH_DATA, which
follows the existing mechanism, by queueing a status-change-update when
cloning the stream. The status-change-update will be run in the
`MediaCache::Update` and it will check what the signal should be sent.
Once the "download-suspended-by-cache=true" is sent, the
"canplaythrough" event of the media-element can be dispatched after
its first-frame is loaded. (The event listeners can possibly make the
media-element starts playing, which is likely to cause a cache-seek that
can revitalize the cache eventually.)
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1646719#c5
Differential Revision: https://phabricator.services.mozilla.com/D92125
Add some logs that can help us to check how many cache-streams are
suspended and the working status in `MediaCache::Update`
Differential Revision: https://phabricator.services.mozilla.com/D92124
`mBlockOwnersWatermark` is introduced in bug 1366936 for telemetry `MEDIACACHE_BLOCKOWNERS_WATERMARK` but `MEDIACACHE_BLOCKOWNERS_WATERMARK` is removed in bug 1356046
Depends on D92106
Differential Revision: https://phabricator.services.mozilla.com/D92107
`mIndexWatermark` was introduced in bug 1366929 for telemetry `MEDIACACHE_WATERMARK_KB` but `MEDIACACHE_WATERMARK_KB` was removed in bug 1356046
Depends on D92105
Differential Revision: https://phabricator.services.mozilla.com/D92106
Removes
- MEDIACACHESTREAM_LENGTH_KB
- MEDIA_PLAY_PROMISE_RESOLUTION
- AUDIO_TRACK_SILENCE_PROPORTION
and all the code I could find that was specific to reporting these values via
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D88868
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
When in private browsing mode and the
'browser.privatebrowsing.forceMediaMemoryCache' pref is set to 'true'
MediaCache::GetMediaCache will only return an in-memory cache to avoid
disk leakage.
Differential Revision: https://phabricator.services.mozilla.com/D22337
--HG--
extra : moz-landing-system : lando
It's possible that `self` is the last pointer holding the media cache, so we have to ensure releasing `self` on main thread because media cache should always be destroyed on main thread only.
Differential Revision: https://phabricator.services.mozilla.com/D58900
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
Randell Jesup
Noemi Erli
Butkovits Atila
Bryce Seager van Dyk
alwu
Simon Giesecke
Jens Stutte
Sylvestre Ledru
Chun-Min Chang
Andreas Farre
Ehsan Akhgari
Narcis Beleuzu
Richard Pospesel
shindli
Gabriele Svelto
Dorel Luca
jeffinsam
Andreas Pehrson
Csoregi Natalia
Dan Minor
arthur.iakab