The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
--HG--
extra : moz-landing-system : lando
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
--HG--
extra : moz-landing-system : lando
Please double check that I am using this correctly. I believe we are
seeing the crash in the linked bug because we are not handling hardware
faults when reading from the memory mapped file. This patch just wraps
all accesses in the MMAP_FAULT_HANDLER_ macros.
Depends on D53042
Differential Revision: https://phabricator.services.mozilla.com/D53043
--HG--
rename : modules/libjar/MmapFaultHandler.cpp => mozglue/misc/MmapFaultHandler.cpp
rename : modules/libjar/MmapFaultHandler.h => mozglue/misc/MmapFaultHandler.h
extra : moz-landing-system : lando
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
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Please double check that I am using this correctly. I believe we are
seeing the crash in the linked bug because we are not handling hardware
faults when reading from the memory mapped file. This patch just wraps
all accesses in the MMAP_FAULT_HANDLER_ macros.
Depends on D53042
Differential Revision: https://phabricator.services.mozilla.com/D53043
--HG--
rename : modules/libjar/MmapFaultHandler.cpp => mozglue/misc/MmapFaultHandler.cpp
rename : modules/libjar/MmapFaultHandler.h => mozglue/misc/MmapFaultHandler.h
extra : moz-landing-system : lando
This is already done for the outer nsJAR, but it wasn't done for the inner nsJAR.
(The omnijar is a nested zip archive on Android: the outer archive is the APK and the inner is the omnijar file.)
So we were re-using the file mapping but not the result of the uncompression.
Differential Revision: https://phabricator.services.mozilla.com/D63970
--HG--
extra : moz-landing-system : lando
A global instance of ZipArchiveLogger is used on multiple threads when the logging is turned on. This patch adds a lock to synchronize the access.
Differential Revision: https://phabricator.services.mozilla.com/D60537
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
We don't want to run stream conversion in the parent (since a lot of them require access to the document), so this instead adds a way to find out what their output type will be.
Differential Revision: https://phabricator.services.mozilla.com/D56134
--HG--
extra : moz-landing-system : lando
