* Resolve custom tab activity issue which hides bottom toolbar
* Only show bottom controls when bottom toolbar is enabled
Refactor activity finish
* override finish to make sure of activity closure
* Add support for diferent variants
* Remove omnibox highlight which shows up right after onboarding
* Add different variants function
* Add search widget promo on NTP
* Add notification permission changes
* Update widget promo UI
* Update wdp check
Resolve presubmit issue
- Moved address bar to bottom on NTP
- Moved menu and updated menu icons and texts
- Added request for relaunch when bottom navigation controls are enabled
- UI and visual improvements
* [ads] Report new tab page ad metrics via confirmation with an optional fallback to P3A
* [ads] Always serve new tab page ads through the component
* [ads] Do not frequency cap last served new tab page ad
* [ads] Deprecate redundant conditon matcher code
* [ads] Transition to v4 confirmation endpoint
* [ads] Include firstTime in the confirmation payload if it is the first impression for the campaign
* [ads] Deprecate HTTP_IM_A_TEAPOT
* [ads] Do not load unnecessary resources
* [ads] Migrate P3A opted-in status
* [ads] Deprecate AdInfoMatchesSponsoredImage
* [ads] Add ad events to brave://ads-internals
* [ads] Optimize firstTime database query
* [ads] Purge ad events when opting out
* [ads] Add grace period
* [ads] General code health
* [ads] Purge Brave News ads for all users when opting out
Chromium change:
https://chromium.googlesource.com/chromium/src/+/6b88305d9871a487e87b7eb9991f5fbe36940d85
[TSLO] Fix status bar coloration in desktop windowing mode
The status bar currently always uses the default tab strip background
color on a tablet when the strip is visible irrespective of the focus
state of the activity window. The strip background color changes from
the default for an unfocused desktop window and if the status bar is
contiguous with an unfocused desktop window, it incorrectly still uses
the default color that is applied only to a focused tab strip.
This CL makes an update to ensure that the status bar uses the same
color applied to the tab strip, which can be impacted by the activity
focus state.
Before:
https://screenshot.googleplex.com/9uKWnPUYcouZFSm
After:
https://screenshot.googleplex.com/AQVoLoAkvwqVvQG
Bug: 393443576
Chromium change:
https://chromium.googlesource.com/chromium/src/+/65edd13188a0eb01fa8e1140b7489a40ee517d52
[bookmarks] Extract manager opening logic to interface/impl
The implementation of this interface can't be modularized. Extracting
the BookmarkUtils methods to an interface/impl combo which can
be used by classes in the bookamrks module.
Bug: 395908100
Chromium change:
https://chromium.googlesource.com/chromium/src/+/088816e5c47905f8b4e16dd867cddaf24fb4f55f
[bookmarks] Modularize bookmarks browser code
Moved production bookmarks browser code to chrome/browser/bookmarks
directory. Made some small changes along the way to simplify the
process.
* Moved all production bookmarks browser code to module.
* Added a separate target for files that can be modularized now.
* Added a separate gni list for files that can't be modularized now
which is included in chrome_java directly. Over time I will refactor
those files so that they are moved into the main modularized target.
* Merged ReadingListUtils and BookmarkUtils. In the long run, browser
reading list code shouldn't really exist since the concepts are
merged at the native level.
* Moved one method from BookmarkUtils to BookmarkModel to allow for
more files to be modularized.
Eventually some files, particularly implementations of interfaces
defined in chrome/browser/bookmarks, will live in the unmodularized
directory.
Bug: 395908100
Chromium change:
https://chromium.googlesource.com/chromium/src/+/e1fc3080db043124e75031b233f0808c057cc78c
Pass profile reference to BookmarkActivities.
Instead of loading getLastUsedRegularProfile, the calling activity will
serialize the current Profile state into the activity and the receiving
BookmarkActivity will use that to load the correct Profile.
While this CL enables the profile loading capability into the base
class of SynchronousInitializationActivity, it is only used by
BookmarkActivity and all other activities should use the legacy code path.
This will be the first production usage of ProfileResolver.
One assertion made in SynchronousInitializationActivity is that if the
profile is not resolved, then the activity will be directly finished.
This will happen in cases where the activity was started with an
incognito profile, then the task is killed by the OS (for debugging,
turn on don't keep activity in Android's developer settings), and
then restarted from recents. I don't think any of these activities
should be recreating the incognito profile that has since been destroyed, and instead should just return to the activity below it in
the task. In the future, we could consider variable recovery paths, but
I think that would be premature optimizations at this point.
Bug: 40254448
Chromium change:
https://chromium.googlesource.com/chromium/src/+/25845008b79c77a30986f99ee9bcbff4a81d10f6
Fix partner bookmark initialization.
PartnerBookmarks were previously being initialized in
ChromeActivity, but not all usage of the BookmarkBridge comes
from ChromeActivity derivatives. In particular if you enable
Don't Keep Activities in Android and load the BookmarkActivity,
then leave, then refocus from recents, it would crash on an
assertion that the partner bookmarks weren't loaded.
To fix the above issue, this moves the PartnerBookmark init
into the process initialization code path that runs once per
application init.
Subsequently, I was trying to move around when the initialization
happened and the internal implementation crashes because it can
not be called on the main thread (no idea why we aren't seeing
this in the wild), so this adds a async way of fetching the down
stream implementation (subsequent patch will utilize it).
Bug: 384197258
Deep Pandya