This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
This should avoid the crash caused by the CacheOutputCloseListener being
fired on the main thread too late during shutdown by keeping the
previous behaviour when on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D165062
Previously this would dispatch to the current thread, which could in
some cases be a threadpool thread, meaning that the runnable would
not run until the threadpool thread exits. This switches the code over
to always dispatch to the StreamTransportService instead.
Depends on D161349
Differential Revision: https://phabricator.services.mozilla.com/D164504
This adds BackgroundTasksRunner utility class as a generic way to properly run background tasks. A few argument for not extending existing BackgroundTasksUtils:
1. Simply because the existing use case is in C++.
2. I have another use case from JSM and thus I'll ultimately convert this an XPCOM component. And `CacheFileIOManager::DispatchPurgeTask` cannot get a JSM-written XPCOM instance which is required to be main-thread only.
Depends on D157998
Differential Revision: https://phabricator.services.mozilla.com/D157757
This background task currently is generic enough that it can be reused for other components, namely QuotaCleaner in the child patches. Renaming makes it clear that it's generic.
Differential Revision: https://phabricator.services.mozilla.com/D156912
We avoid the race by cloning the file before calling GetParent, to avoid
writing to mCacheDirectory's buffer on the main thread during shutdown,
when called from SyncRemoveAllCacheFiles.
Additionally, we dispatch OnDelayedStartupFinished to the IO thread
to avoid accessing mCacheDirectory on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D155798
This patch uses a CachePurgeLock for every directory it deletes.
Because we can't possibly know if a folder was already deleted before we
aquire the lock or if it never existed (without the use of a log file) we
can assume that if a folder isn't there after the timeout has expired it's
already been purged by a different cleanup task.
Depends on D132164
Differential Revision: https://phabricator.services.mozilla.com/D132165
Purge HTTP disk cache using backgroundtasks
Motivation:
In the History settings preferences panel you may choose to
`Clear History when Firefox closes` - which sets the
`privacy.sanitize.sanitizeOnShutdown` pref.
If the `Cache` checkbox is also checked it sets the
`privacy.clearOnShutdown.cache` pref to true.
When both of these prefs are true `CacheObserver::ClearCacheOnShutdown()`
will return true, which will cause Firefox to clear the HTTP disk cache
during shutdown. This will block shutdown for howeverlong this takes. If the
user has a slow disk, or the user is on Windows and something is blocking the
deletion of those files, this will trigger a shutdown hang making Firefox
crash. This leads to a bad user experience as trying to start Firefox again
during this time will show the "Firefox is already running message".
Eventually a crash dump is produced. Bug 1356853 and bug 1682899 are caused
by this specific issue.
In order to avoid these crashes and a bad user experience we have
a few options:
1. Completely disable the disk cache when a user checks this box.
This option will degrade the user's browsing experience.
2. Don't delete the folder at shutdown
Whether we do this by removing the checkbox or simply not respecting
the pref value, users who already have this setting would be surprised
if the cache folder stops being deleted.
3. Use a thread pool to delete the files
While it's likely to speed up the deletion at least a little bit,
this would introduce additional complexity while not completely
fixing the issue. A slow disk will still block shutdown.
4. Delete the cache at shutdown using a separate process
This is likely the best option. It has the advantage of not blocking
shutdown while at the same time maintaining similar properties to the
existing functionality:
- The cache folder is deleted at shutdown.
- Has the same behaviour if Firefox gets killed or crashes for different issues.
- Behaves similarly if the OS is forcefully shutdown during or before we begin to purge.
- Additionaly, because we rename the folder prior to dispatching the background task, if the purging isn't completed we
- don't rebuild the cache from an incomplete folder on next restart
- are able to resume the purging after Firefox startup
A particularly special case is the Windows shutdown.
If the user shuts down windows that will try to close Firefox. If the shutdown
takes too long, the user will see the "Close anyway" button and may click
it thus preventing the cache purge to complete.
When using a background task we have a similar situation, but the button won't
even appear. So after the next Firefox restart we will check if the cache
needs to be purged.
Largely, the new behaviour will be:
- At shutdown we conditionally dispatch a background task to delete the folder
- If creating the process fails (for some reason) we fallback to the old way
of synchronously deleting the folder.
- The task will then try to delete the folder in the background
- If for some reason it fails, we will dispatch a new background task shortly
after Firefox restarts to clean up the old folders.
Differential Revision: https://phabricator.services.mozilla.com/D126339
In CacheFileIOManager::GetEntryInfo(), there is only a problem if the Alt Data
element is present but we can't parse a reasonable value out of it (a value
smaller than the metadata offset).
Differential Revision: https://phabricator.services.mozilla.com/D146467
Andi-Bogdan Postelnicu
Kagami Sascha Rosylight
Iulian Moraru
Nika Layzell
Sandor Molnar
Valentin Gosu
Noemi Erli
edgul
Mathew Hodson
Dana Keeler
Marian-Vasile Laza
Butkovits Atila
Randell Jesup
Cristian Tuns
Mark Banner
Manuel Bucher
edguloien
Narcis Beleuzu
Bryan Thrall