This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This changeset is the result of adding modernize-use-default-member-init to
tools/clang-tidy/config.yaml then proceeding to run
`./mach static-analysis check netwerk/ --fix`
I then went through the resulting fix and manually updated all of the member
variables which were missed due to them having a non-trivial constructor.
Note that the tool was only run on Linux, so code that only runs on some
platforms may have been missed.
The member variables that are still initialized in the contructor definition
are:
- bitfields (not all currently supported compilers allow default-member-init
- variables that are initialized via a parameter
- variables that use code not visible in the header file
There are a few advantages to landing this change:
- fewer lines of code - now declaration is in the same place as initialization
this also makes it easier to see when looking at the header.
- it makes it harder to miss initializing a member when adding a new contructor
- variables that depend on an include guard look much nicer now
Additionally I removed some unnecessary reinitialization of NetAddr members
(it has a constructor that does that now), and changed nsWifiScannerDBus to
use the thread-safe strtok_r instead of strtok.
Differential Revision: https://phabricator.services.mozilla.com/D116980
This changeset is the result of adding modernize-use-default-member-init to
tools/clang-tidy/config.yaml then proceeding to run
`./mach static-analysis check netwerk/ --fix`
I then went through the resulting fix and manually updated all of the member
variables which were missed due to them having a non-trivial constructor.
Note that the tool was only run on Linux, so code that only runs on some
platforms may have been missed.
The member variables that are still initialized in the contructor definition
are:
- bitfields (not all currently supported compilers allow default-member-init
- variables that are initialized via a parameter
- variables that use code not visible in the header file
There are a few advantages to landing this change:
- fewer lines of code - now declaration is in the same place as initialization
this also makes it easier to see when looking at the header.
- it makes it harder to miss initializing a member when adding a new contructor
- variables that depend on an include guard look much nicer now
Additionally I removed some unnecessary reinitialization of NetAddr members
(it has a constructor that does that now), and changed nsWifiScannerDBus to
use the thread-safe strtok_r instead of strtok.
Differential Revision: https://phabricator.services.mozilla.com/D116980
The crash happens currently when there are more than one loading session history entries at the same time and when
the latter load then accesses current active entry, it has already the bfcached frameloader.
I have tried and failed to write a testcase for this. The Pernosco record is from running
https://searchfox.org/mozilla-central/source/devtools/client/webconsole/test/browser/browser_webconsole_message_categories.js
and the crash has happened when there is a race condition between a load initiated in the parent process and another load initiated in a child
process.
The patch tries to make the setup rather safe. If active entry has changed or it has gotten frameloader, don't try to bfcache.
Differential Revision: https://phabricator.services.mozilla.com/D116410
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This patch adds a UnstrippedURI into the LoadInfo. This attribute
represents the channel's URI has been stripped if this attributes is not
a nullptr.
Having this attribute allows us to be able to revert the query stripping
in the case where the loading channel is in the content blocking allow
list in the parent process.
In addition, this patch removes the main thread assertion in URIUtils
given that we've made the URL construction thread-safe. This will allow
us to be able to use nsIURI directly in ParentLoadInfoForwarderArgs.
Differential Revision: https://phabricator.services.mozilla.com/D116108
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This allows loads to be tracked as they are ongoing on a per-context basis in
the parent process, and for events to be generated for each subframe as it is
destroyed.
This patch also stops sending the `IsLoadingDocument` flag on the request to
the main process and removes RemoteWebProgress, as they are no longer necessary
due to being tracked directly.
Finally this patch also adds some logging to BrowsingContextWebProgress
to make it easier to diagnose this type of issue in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115706
This patch adds a flag 'needForCheckingAntiTrackingHeuristic' in
loadInfo. This flag will be used for deciding if we need to check the
AntiTracking heuristic after the channel has been classified.
Differential Revision: https://phabricator.services.mozilla.com/D107047
Previously, we would need to suspend progress events from the previous
BrowserParent, as otherwise we would receive STATE_STOP progress notifications
from the previous browser when it is destroyed, which would throw off frontend
code. With the new checks added by part 1, we will now catch these cases by
detecting that the current window global has changed, and we can get rid of this
explicit override.
Differential Revision: https://phabricator.services.mozilla.com/D105557