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
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
UI needs to distinguish the cases when a channel is shimmed and is
unshimmed.
When a channel is unshimmed, we unblock the channel and simply treat the channel as a
non-tracking channel.
When a channel is shimmed, although the channel is unblocked by
URLCLassifier, we still want to show it in the UI. For this case,
URLClassifier will notify a content blocking event when a channel is
unblocked.
This patch adds a new allow API, so the caller can use unblock() or
allow() depending upon the case it requires.
Differential Revision: https://phabricator.services.mozilla.com/D93271
This patch does the following:
1. Introduce a new log module "nsChannelClassifierLeak" for less
important debug message
2. Sync the format of debug message - "ClassName::FunctionName - description [this]"
3. Print uri and top-level uri in the entry point of
AsyncChannelClassifier, remove logging uri in some functions
Differential Revision: https://phabricator.services.mozilla.com/D83610
This patch does the following:
1. Introduce a new log module "nsChannelClassifierLeak" for less
important debug message
2. Sync the format of debug message - "ClassName::FunctionName - description [this]"
3. Print uri and top-level uri in the entry point of
AsyncChannelClassifier, remove logging uri in some functions
Differential Revision: https://phabricator.services.mozilla.com/D83610
ShouldEnableClassifier checks two things:
1. If AddOn can load the channel
2. If the classified channel is top-level.
For the first point, we added the check in Bug 1308640, and I think the
idea is only for tracking protection to not block channels when
extensions have permission on the channels' domain.
For annotation features, we should always annotate a channel regardless of whether
it is controlled by extensions (also for ETP).
And since we use first-party classification flag in channels, so we
should also annotate channel no matter it is top-level, first-party or
third-party.
So this patch removes calling ShouldEnableClassifier in annotation
features and also rename ShouldEnableClassifier to
ShouldEnableProtectionForChannel to make the idea more clear.
Differential Revision: https://phabricator.services.mozilla.com/D82504
Channels loaded by service worker don't have loadcontext, so we don't
apply tracking protection on them.
Depends on D80183
Differential Revision: https://phabricator.services.mozilla.com/D80184
When a channel is initiated from sharedworker or service worker, we use
worker's origin as the top-level uri.
Depends on D80182
Differential Revision: https://phabricator.services.mozilla.com/D80183
We use whether channel->GetTopWindowURI returns a failure to determin
if the channel is a top-level load. However, channels loaded by service
worker or appcache don't have top-level window.
This patch use TYPE_DOCUMENT to determin whether it is a top-level load.
This patch also adds UrlClassifierCommon::GetTopWindowURI to print debug message
because nsIChannel::GetTopWindowURI is not fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D80182
Channels loaded by service worker don't have loadcontext, so we don't
apply tracking protection on them.
Depends on D80183
Differential Revision: https://phabricator.services.mozilla.com/D80184
When a channel is initiated from sharedworker or service worker, we use
worker's origin as the top-level uri.
Depends on D80182
Differential Revision: https://phabricator.services.mozilla.com/D80183
We use whether channel->GetTopWindowURI returns a failure to determin
if the channel is a top-level load. However, channels loaded by service
worker or appcache don't have top-level window.
This patch use TYPE_DOCUMENT to determin whether it is a top-level load.
This patch also adds UrlClassifierCommon::GetTopWindowURI to print debug message
because nsIChannel::GetTopWindowURI is not fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D80182
The argument aEventTarget is actually never used by any caller; nullptr is always passed for it.
But the code is there in case it isn't null which would call into IProtocol::SetEventTargetFor
Depends on D80419
Differential Revision: https://phabricator.services.mozilla.com/D80421
Valentin Gosu
Csoregi Natalia
Butkovits Atila
Paul Zuehlcke
Alexis Beingessner
Masatoshi Kimura
Narcis Beleuzu
Dorel Luca
Simon Giesecke
Ricky Stewart
Bogdan Tara
Dimi Lee
Sylvestre Ledru
Kris Maglione
Razvan Maries
Andrea Marchesini
Noemi Erli
Jean-Yves Avenard