A new static assertion has been added upstream and otherwise the
build will fail for Linux now, as well as for other platforms in
the next release.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/ad0da8ebec488b6b3696b44d2da80744f8a90d17https://source.chromium.org/chromium/chromium/src/+/63714a9ffe267a0212f4120a188f45408555a993
commit ad0da8ebec488b6b3696b44d2da80744f8a90d17
Author: Daniel Cheng <dcheng@chromium.org>
Date: Mon Feb 22 21:07:22 2021 +0000
Disallow base::Passed() from being used with base::BindOnce().
The assert is currently only enabled on OS_LINUX. Platforms will be
incrementally fixed until the assert is enabled everywhere.
Bug: 1180750
commit 63714a9ffe267a0212f4120a188f45408555a993
Author: Daniel Cheng <dcheng@chromium.org>
Date: Fri Feb 26 09:51:28 2021
[base] Disallow base::BindOnce() + base::Passed() use on iOS.
std::move() and base::Passed() mean the same thing for base::BindOnce(),
so use the standard library idiom instead.
Bug: 1180750
This type is now deprecated upstream and cleared from preferences (as
it's considered obsolete) now when starting chromium, so let's drop
the remaining references from the code and fix a build issue at the
same time now that upstream's EphemeralProvider has been removed.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/ce14b8610aa681638eb5063c5013518d387e545e
commit ce14b8610aa681638eb5063c5013518d387e545e
Author: Illia Klimov <elklm@google.com>
Date: Wed Dec 9 21:20:36 2020 +0000
Remove Ephemeral provider.
Flash has been removed from Chrome almost entirely. Ephemeral provider
was used only by these two content settings - PLUGINS and
PERIODIC_BACKGROUND_SYNC. PERIODIC_BACKGROUND_SYNC is no longer
registered and PLUGINS is deprecated.
Bug: 1149381
These constants were previously defined in a different namespace
(i.e. ChromeBrowsingDataRemoverDelegate) and have been now moved
into chrome_browsing_data_remover instead.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/e7eca7b2ee50d035dea12e055c36823666f697b8
commit e7eca7b2ee50d035dea12e055c36823666f697b8
Author: Glen Robertson <glenrob@chromium.org>
Date: Thu Nov 26 03:52:57 2020 +0000
Separate ChromeBrowsingDataRemover constants from Delegate
Constants that were defined in chrome_browsing_data_remover_delegate.h
have been moved to a separate header in its own gn target, so that
dependents like profile can avoid taking a dependency on all of
//chrome/browser:browser just for access to the constants.
This is done in prep for moving profile out of the //c/b target.
Bug: 1149277
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/e7eca7b2ee50d035dea12e055c36823666f697b8
commit e7eca7b2ee50d035dea12e055c36823666f697b8
Author: Glen Robertson <glenrob@chromium.org>
Date: Thu Nov 26 03:52:57 2020 +0000
Separate ChromeBrowsingDataRemover constants from Delegate
Constants that were defined in chrome_browsing_data_remover_delegate.h
have been moved to a separate header in its own gn target, so that
dependents like profile can avoid taking a dependency on all of
//chrome/browser:browser just for access to the constants.
This is done in prep for moving profile out of the //c/b target.
Bug: 1149277
The problem is the TracingDataTypes are stored in a set, so if you re-use one of them that's already used it will crash.
See `std::set<TracingDataType> pending_sub_tasks_`.
So I just patched in a new tracing data type and now the crash is gone.
With the migration away from ResourceIds, the BraveSiteSettingsCounter
class is no longer needed, since upstream's SiteSettingsCounter will be
good enough now that we don't need to perform a "subsearch" for the
ContentSettingsType::PLUGINS type, to consider Brave-specific cases.

In this new worls where we have Brave-specific ContentSettingsTypes,
SiteSettingsCounter::Count() will suffice to account for Brave's own
ContentSettingsTypes, so there's no need to have a subclass to deal
with them now, therefore we have to remove it (otherwise the count
won't be correct, at least in its current form, since the same type
would be counted twice).
As part of upstream bug 1134547[1], the ResourceIdentifier that Brave
Shields relied on so far has been completely removed[2], so we need to
adapt our code not to rely on it anymore so that we can keep building
Brave correctly on the latest dev channel release of Chromium 88.
This patch implements the first step to adapt Brave to this new
scenario, by moving into using Brave-specific values of the
ContentSettingsType enumeration instead of using the PLUGINS
type plus a ResourceIdentifier as we did before.
Note that this patch adds a "bs_" prefix to all the BraveShields
constants, to avoid collisions with the COOKIES and JAVASCRIPT
upstream content types. Added prefix to all constants for
consistency + update TS code.
Note that the goal of this change is simply to keep Brave building,
running and passing the tests so that we can continue working on the
rebase. Further work will be still needed in follow-up patches to
fully migrate the code base to a post-Flash world by changing those
bits that don't make sense anymore, and simplifying things as much
as possible.
[1] https://crbug.com/1134547
[2] https://crrev.com/c/2500161
Profile prefs are now used for saving publisher / source enabled or disabled. This is more future proof as this data is not ephemeral.
Also provides a method for resetting those prefs from the NTP "customize" panel. Now that this is a regular profile pref, this could also be cleared from the regular Settings page.
Sets up an event flow from clearing history to the background process which caches the feed. It's important to clear the feed cache when the history is cleared since the feed assigns higher rank to content from hosts that the user has previously visited.
Also allows Today to be turned on and off.
Remove unnecessary includes header files and
add missing dependencies to the proper targets.
Additionally, this PR copies TranslateManagerTest from
upstream code to TranslateManagerUnittest in order to
avoid touching the upstream code. Then, this PR renames
the file to brave_translate_manager_unittest.cc.
Resolvesbrave/brave-browser#10613.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/b06b34efeb4d6648d9b014c7cf8bf5e73284b69c
commit b06b34efeb4d6648d9b014c7cf8bf5e73284b69c
Author: Ramin Halavati <rhalavati@chromium.org>
Date: Thu Sep 3 12:01:34 2020 +0000
Remove defaults from Profile::[Get/Has]OffTheRecordProfile().
The default values for OffTheRecord profile functions are removed and
all remaining use cases are replaced with [Get/Has]PrimaryOTRProfile.
The cases that need further update later are marked with TODO.
This CL does NOT change any behavior.
Bug: 1033903
With visibility handler added `chrome::GetTotalBrowserCount` was always
returning a non-zero count. Instead of checking on main thread tear
down, check is moved to browser process tear down.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/7492117659dab49c3f4d7c16af696af428e5e3a1
commit 7492117659dab49c3f4d7c16af696af428e5e3a1
Author: Marc Treib <treib@chromium.org>
Date: Tue Jul 7 15:19:56 2020 +0000
[CBD] Wire password deletion failure to the UI
Before this CL, BrowsingDataRemover did not expose the concept of
"deletion failure", i.e. when a requested deletion could not be
completed. (An example of such a deletion failure is a timeout, which
BrowsingDataRemoverImpl sets to 30 seconds.)
This CL adds the concept of "failed data types" to the API. They're
represented as a bitmask of DataTypes - the same format that's used to
request deletion in the various Remove*() methods.
So far, the only data type that will actually report deletion errors is
DATA_TYPE_PASSWORDS, but support for more types can easily be added.
None of the clients/observers does anything with the new information
yet; that's left for a future CL.
Bug: 1086433
Chromium change:
https://chromium.googlesource.com/chromium/src/+/c3305c04ac6800d488bfc8b2f3249fd13186984a
commit c3305c04ac6800d488bfc8b2f3249fd13186984a
Author: Marcus Pasell <mapasell@microsoft.com>
Date: Wed Jun 3 22:14:36 2020 +0000
Update OriginType and DataType enums to uint64_t
Update the enums used by the BrowsingDataRemover to be 64bit unsigned
to make room for future additions. Update usages and bitmasks to also
reflect this change.
Bug: 668114
Chromium change:
https://chromium.googlesource.com/chromium/src/+/f62a1294a4b54626abf1275e47057e5564a7bb3a
commit f62a1294a4b54626abf1275e47057e5564a7bb3a
Author: Brandon Maslen <brandm@microsoft.com>
Date: Wed Apr 29 07:37:10 2020 +0000
Update Content Settings to Utilize Time/Scope Restrictions to Get/Set Settings.
Currently all content/website settings are not bounded or scoped aside
from possibly being ephemeral and held in memory only. In order to
support scenarios for the Storage Access API and future permission
time-boxing efforts the concept of scoping settings is needed.
This change introduces the notion of a ContentSettingConstraints struct
that can be optionally provided when setting a content or website
setting. The constraint consists of an optional base::Time to
specify the expiration that a setting should use,as well as a
SessionModel to specify the lifetime model of the setting.
The following initial SessionModel have been specified; however, future
options such as TabOnly may be added to accommodate permissions scoping:
Durable: Settings persist forever and are bounded only by an expiry
date, if set. Will be persisted to disk to survive session
restarts.
UserSession: Settings will persist no longer than a user session
regardless of expiry date, if set.
All types of scopes may be constrained by an upper bound duration. This
allows settings to expire after a set period of time has passed.
The majority of this new behaviour is contained within the
HostContentSettingsMap and associated Providers and supporting classes.
New constraint parameters have been added as optional to setters and
unless opted in by new callers will behave as they did prior to this
change. The getters have been updated so that a direct retrieval of
a setting will only return a value if a currently un-expired setting
exists. If an array of values is retrieved for future use like with
GetSettingsForOneType the expiry date and convenience method
IsExpired() have been added to ensure consumers can accurately
determine if a setting is relevant.
In order to cleanup expired Durable entries we will validate the
expiration time on entries, if set, when we read our settings from
prefs. If present any expired entries will be cleaned up at this time.
New test cases have been added to validate the HCSM behaviour changes
as well as the PrefProvider and supporting classes.
In addition to this the first consumer of these changes has been added
in the Storage Access API permissions context code. This ensures that
the API can both set either a UserSession or Durable grant with an
associated duration as well as determine the number of existing grants
that are UserSession only as required.
Bug: 989663
GURL constructor uses scheme registry which now DCHECKs if accessed
before being initialized with schemes.
Converted BraveStatsUpdater::g_base_update_url_ to std::string.
Converted SuggestedSitesProvider::suggested_sites_ to method local
static.
Converted oauth_url in binance_service.cc to const char[].
Also, moved inside functions in several unit tests.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/2add7d44778f7be638639aeb26a3b14f0b222e09
commit 2add7d44778f7be638639aeb26a3b14f0b222e09
Author: Michael Thiessen <mthiesse@chromium.org>
Date: Wed Feb 5 13:49:38 2020 +0000
Lock SchemeRegistry on first use.
This change locks the SchemeRegistry on first use, which required
refactoring url_util.cc to differentiate between SchemeRegistry use for
adding Schemes, and SchemeRegistry use for using Schemes.
Tests can now only modify schemes after initialization by calling
url::UnlockForTests(), which creates a scoped object that resets the
schemes, so tests can't mistakenly leave global scheme state modified.
This change required changes to browser startup to decouple scheme
registration from ContentMain, found here:
https://chromium-review.googlesource.com/c/chromium/src/+/1945926
Doc: https://docs.google.com/document/d/1kDKqBaq-b6EbUm0F4ea7ARoksUcj1KUx3qxFuSXEwM4/edit
Bug: 783819
Migrates all shields settings patterns to use wildcard for protocol and port.
This was needed for cookies due to Chromium change that uses
SiteForCookies which doesn't contain port information to match settings
patterns.
However, using wildcards for protocol and port makes sense for all
shields settings.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/5d02d9e0ab081fb052eed0ab65581fb5b4622fa4
commit 5d02d9e0ab081fb052eed0ab65581fb5b4622fa4
Author: Maks Orlovich <morlovich@chromium.org>
Date: Sun Dec 15 22:14:10 2019 +0000
Give ResourceRequest::site_for_cookies proper type.
(With net::RedirectInfo matching it as well).
It previously being a URL was highly misleading since:
1) There was a special meaning to empty URLs
2) The path bits weren't really guaranteed to exist.
... And also having a dedicated type will simplify computations by
centralizing the use... in following CLs.
Bug: 577565
So far, shields settings are also cleard with "All time" time range.
With "All time" range option, browser nuke whole plugins type data.
With non "All time" range option, browser only clears plugins type for
empty resource ids which is flash type.
This commit makes browser clear shields data also with non "All time" range.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/ae8a5b1faf6dee0e2363ce04a9bad6b073b7baeb
commit ae8a5b1faf6dee0e2363ce04a9bad6b073b7baeb
Author: Greg Thompson <grt@chromium.org>
Date: Thu Nov 21 12:35:36 2019 +0000
Reland: Browser shutdown cleanups (no functional changes).
- Make ShutdownType an enum class.
- Introduce browser_shutdown::HasShutdownStarted as a convenience.
- Switch from UMA macros to functions for one-shot metrics.
(cherry picked from commit 11936b318f36c4624c9bcba47f61f65cf457dc20)
BUG=958865
Chromium change:
https://chromium.googlesource.com/chromium/src/+/9ce426007956a2db57f880721c247c0c8a824de6
commit 9ce426007956a2db57f880721c247c0c8a824de6
Author: Evan Stade <estade@chromium.org>
Date: Mon Jul 29 23:56:14 2019 +0000
Remove test util class BrowserAddedObserver
It used NOTIFICATION_BROWSER_OPENED.
Most of the time in these tests, the new browser is opened
with chrome::NewWindow or chrome::NewEmptyWindow, which
are usually synchronous, so waiting is not needed. The
exception is when they trigger session restore, and in
those cases it's sufficient to use
SessionRestoreTestHelper::Wait.
Bug: 268984
Fixesbrave/brave-browser#492
1. Adds a new "On exit" tab to chrome://settings/clearBrowserData dialog
with the same options as on the "Advanced" tab and a "Save" button. By
default all "On exit" options are turned off. When an option is modified
from the current state the Save button becomes enabled and allows the
user to save the "on exit" options. The options are saved to profile's
preferences: new *OnExit preferences have been added for each option.
2. Clear browsing data on exit functionality is triggered from
BraveBrowserMainParts::PreShutdown override. For each loaded profile
the code checks if user selected any on exit options and if so then a
BrowsingDataRemover is called.
3. Adds BraveClearDataOnExitTest and BraveClearDataOnExitTwoBrowsersTest
browser tests that verify that:
- the removal of the browsing data is triggered only when an "on exit"
preference is set;
- the removal flags are constrcuted correctly;
- the removal is called only when the browser is exiting (tests with
OTR/Guest/multiple profiles).
Mario Sanchez Prada