This fixes Lint error
```
../../brave/android/java/org/chromium/chrome/browser/bookmarks/BraveBookmarkManagerMediator.java:156: Warning: Using name is unsafe as it is a filename obtained directly from a ContentProvider. You should sanitize it before using it for creating a File. [UnsanitizedFilenameFromContentProvider]
File file = new File(mContext.getFilesDir(), name);
~~~~
```
Related Chromium change (android-security-lints):
https://github.com/google/android-security-lints/pull/8/files
Upload @TudorMagirescu's UnsanitizedFilenameFromContentProvider lint check
Related Chromium change:
https://source.chromium.org/chromium/chromium/src/+/669963ea86e76265f27de29b3925df97b4b8ea83
[Settings] Make the activity responsible for setting the title
Today, each setting page implementation mutates the activity's title by
calling getActivity().setTitle(). This is problematic as we redesign the
setting UI for two primary reasons: (1) we are going to show the page
title in the header of the detail pane, not as the activity title (2) we
have to restore the page title when the user hits the back button after
we migrate from the activity-based UI to the fragment-based UI.
This patch rewrites all existing setting page implementation to tell the
settings activity their page name, instead of directly mutating the
activity title.
For this purpose, this patch introduces a new interface SettingsPage to
be implemented by all fragments that can be shown as a setting page.
a few lines in the file
Low-Coverage-Reason: TRIVIAL_CHANGE Interface change that modifies only
Bug: b/356743945
Change-Id: I73a0db0b384850385cdce1ebb8077a96c761d7ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5804482
- new argument at BottomControlsMediator.ctor - browserControlsVisibilityDelegate
- new argment at BottomControlsCoordinator.ctor - browserControlsVisibilityDelegate
Related Chromium change:
https://source.chromium.org/chromium/chromium/src/+/d813d2e1ad66f8954e2e1da0821fa55eb9a21a70
Force browser controls to show up when creating new tab group
When tab group is created via long press context menu, it'll triggers SimpleAnimationLayout then shows the tab group. This flow will detach the current tab and add it back; during this process, the new browser controls height, which is changed due to tab group UI being added, does not dispatched to the render. This causes a bug when the tab is reattached and becomes interactable, the offset read from TabBrowserControlsOffsetHelper is stale, leaving the tab group UI scene layer on the screen.
This CL work around this by forcing the browser controls to be visible when the tab group UI becomes from hidden to visible. This has no impact to flows other than context menu -> "open new tab in group", as switching tabs will force browser controls to show transiently already.
Bug: 357398783
Change-Id: I419b9303b033f0f621956952bc61c56a199fc338
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5809240
* AI Chat: Introduce AIChatService, ConversationHandler, and direct bindings from UI
Modified AIChat WebUI to directly bind to both AIChatService and ConversationHandler for most operations.
Lays the groundwork for conversations to be independent of web content. In fact, most of this functionality is also within this PR. Conversation persistance (in-memory) is guarded behind a feature flag.
Refactor print preview extractor to be passed to AIChatTabHelper directly
Also removed max page content consideration since:
1) Model can be changed after fetching the content
2) Multiple callbacks could occur with different page content limits from different conversations
3) We need to know the (reasonable) total content length to report the percentage of content that Leo has been sent.
I did consider sending the requested page content maximum length for each GetContent call, but that does not solve all the issues. Since there is a maximum limit of 20 print preview pages, it seems it's ok.
kAIChatHistory flag -> AIChatHistory
* ConversationHandler doesn't need to deal with navigation ID
* test fix
* AIChatTabHelper params instead of multiple test. Always trim content.
* test and review feedback - comments, id->uuid, page-navigation-tests
* fix for android build
* fix same-document back/forward navigation by considering page title changes during navigation
* ios refactor
* Fix compiling on iOS. Fix Service registration crash.
* Fix crashes on iOS. Fix logic so AIChat on iOS works correctly. Fix models list conversion to iOS.
* fix ConversationHandler::GenerateQuestions, refactor non-conversation rewriting out of ConversationHandler, test ConversationHandler::GetState
* feedback
* fix AIChatRenderViewContextMenuBrowserTest
* don't wait for client connection before submitting human message
* AIChatService::MaybeAssociateContentWithConversation
* feedback
* android HandleVoiceRecognition now optionally passes ConversationId to target a specific conversation
* feedback
* fix ModelService migrating from chat-claude-instant default model pref value
* feedback
* format
* rebase fixes
* AIChatTabHelper refine and test retry logic
* fix android compile
* fix android again
* no channel_info new string
* associatedcontentdriver - remove is_page_text_fetch_in_progress_
* ConversationHandler::HasAnyHistory ignores staged entries
* AIChatService: erase from content_conversation map, and test it
* MaybeUnlink should check if client is connected
* fix android again?
* ChromeAutocompleteProviderClient should check AIChatService exists
---------
Co-authored-by: Brandon T <JustBrandonT@gmail.com>
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/af4a1a29660d0cfa1ed074d69f782abc9f79fd98
Make NotificationPlatformBridge less native-dependent (3/5).
Mark as `static` several helper methods in `NotificationPlatformBridge`. This is in preparation to enable calling methods like `displayProvisionallyUnsubscribedNotification` without an instance of
`NotificationPlatformBridge` existing, which requires native
libraries to be loaded.
As these methods already access no instance variables, there should be no functional changes.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/3f2127c8345e1a34106b4f64bfa7836508af360d
[Android] Do not use Dagger for EphemeralTabCoordinator
EphemeralTabCoordinator relied on Dagger to get itself injected to
CustomTabDelegate{Factory} which owns the object. This CL moves it
out to BaseCustomTabRootUiCoordinator, and strip all the injection
annotations off it. This move makes it easy to modularize
EphemeralTab for upcoming changes.
Low-Coverage-Reason: HARD_TO_TEST Warning from BaseCustomTabRootUiCoordinator whose coverage is low before the CL.
Bug: 355482871
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/f86505e301c4ccca5b485df3b58c833d3f808447
refactor: remove unused x,y from BackGestureEvent
These values are unused as the progress field is what drives all
effects. Tests aren't bothering to set these correctly so lets remove
this and all the associated plumbing.
Change-Id: I93bcad6a3932be222689243e2a9413e80bf78572
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/b636fee560d66a2fe444b094564615d9585c9080
[Toolbar] Move tab switcher button to existing coordinator.
We already have a ToggleTabStackButtonCoordinator which only handled pageload IPH. Moved the button logic from ToolbarPhone/Tablet to this coordinator.
Also removed standard code in TabStackButton view related to click listeners. Move standard properties from code to xml.
Verified tooltip / button click and long click WAI on phone and tablet
Change-Id: I28dbfac2a2d2565d9dbc70331d7fe5a275355587
Bug: 355074249
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/2bec252dc800a55defad9247c0e1f7f98c8df86c
[Tab Model] Use TabClosureParams
This CL deprecates all the flavors of tab closure in the TabModel in
favor of a single `closeTabs` method with a set of params.
There are no logical changes inside TabModelImpl in this CL although it
should now be possible to steamline the flow if we so choose.
The main impetus for this change is that we will be introducing warning
in certain contexts when closing a tab may result in loss of data.
Having a single consistent API for closing tabs will allow us to
introduce patterns such as the one below without needing to awkwardly
forward args and dispatch to the right method on TabModel.
Additionally the TabClosureParams are a lot cleaner, more extensible,
and easier to reason about than lists of several booleans in a row as
was the previous the case. For example; one might consider introducing
a close tab group param using the TabGroupId as a key rather than a
list of tabs. With this new API that is realtively easy and the
TabGroupId can be resolve to a list of tabs in the TabModelImpl.
```
closeTabsWithPossibleWarning(TabClosureParams params) {
if (!shouldWarn(params)) {
tabModel.closeTabs(params);
return;
} else if (shouldCreateNtp(params)) {
// Prevent a tab group from closing by adding an NTP.
createTab();
tabModel.closeTabs(params);
return;
}
Callback<Integer> dialogResult = (result) -> {
if (result == ACCEPT) {
tabModel.closeTabs(params);
}
};
ModalDialogManager.showDialog(...);
}
```
Low-Coverage-Reason: LARGE_SCALE_REFACTOR only ChromeTabbedActivity is lacking coverage.
Fixed: 356445932
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/046c1821365871ee2918e6e266cb6ebe8e0306d6
Rename variable networkHandle to targetNetwork in CustomTabs
This CL renames the networkHandle to targetNetwork in CustomTabs code
base, which keeps the naming consistent with the native layer. And use
NetId.INVALID to replace the constant DEFAULT_NETWORK_HANDLE defined
in the WebContentsFactory class.
Bug: 340528507
AlexeyBarabash
