* Tweak background video playback description in flag page
* Remove redundant call to allow Javascript injection
The method `content::RenderFrameHost::AllowInjectingJavaScript()` is already called in
`background_video_playback_tab_helper` for those domains that correctly have a match so
it's not needed in `brave_browser_main_parts`.
* Fix boolean logic
* Make `IsBackgroundVideoPlaybackEnabled` method more readable
* Remove unneeded predefined default value from XML
* Refactor logic and remove old code
* Enable background video playback preference by default
* Remove unused constant
* Remove usage of `BravePrefServiceBridge` for boolean background video playback
* Use mTabModelProfileSupplier as settings UI always use original profile
* [Android] New Mobile Bookmarks homepage setting
* [Android] Mobile bookmarks string correction
* [Android] Code review suggestions
* Replaces direct patch with bytecode and adds eol
* Moves test method from dummy to the main class
* Direct patch xmls and typo fix
* BaseJUnit4ClassRunner to ChromeJUnit4ClassRunner for tests
* Fixes presubmit issues for tests
Chromium change:
https://chromium.googlesource.com/chromium/src/+/b875fe9e2f6b613d0207655bd970a34427210f0d
[Android][3PPWM] Ignore IsEnabled and load config timely for CCTs
CCTs create webContents in a way that doesn't allow reading the pref
before the autofill machinery is initialized. With this CL, the pref
value is passed in on creation which fixes the issue.
Another, less frequent issue is checking isEnabled. This method lazily
initializes Android's AutofillManager and contributes to CCTs
occasionally preventing Autofill use. This is incorrect since the return
value may change while the app is running and isn't suitable for making
an initial decision about whether Autofill should be enabled. The
safeguard this provided is (already or by now) checked in the Android
Framework when the regular notifyViewEntered calls are invoked.
Just out of caution and because this fix affects a fully launched
feature, both changes are guarded with a new feature:
kAutofillVirtualViewStructureAndroidInCct.
Unlaunching the original feature isn't a good option but holding this
fix back is a bad option, too. Therefore, it's default-enabled and
intended to use only as a possible kill-switch.
The change shouldn't affect WebView but we'll add a flag as guard.
go/scrcast/NTMyNTYxNTEwMzIxMzU2OHw1OTZhYTJlZC02Yg
(cherry picked from commit 5bd3d05740695f1e55c34415cb77bdea0e04759c)
DD: go/3ppwm-dd
Bug: 411164104
Fixed: 415734605
Change-Id: Iaf8ac48eef3fbf833d49d67c3e427d8c8d4d53b5
Chromium change:
https://chromium.googlesource.com/chromium/src/+/19050b6adac2e1f9b0442fc2dc4e58e5e023b251
Make AppMenuPropertiesDelegateImpl abstract.
Previously, the base class had all the logic for tabbed mode, and that
was never accessed by other child classes. This moves the tabbed logic
to the TabbedAppMenuPropertiesDelegate and make the base class abstract.
One of many CLs to try and remove XML menu inflation from the app menu.
Bug: 40145539
Chromium change:
https://chromium.googlesource.com/chromium/src/+/44b0ddd43212a03a3a9c7a66c08cd3a0f52b7e4b
[mobar] Suppress top toolbar scene layer while mini origin bar is active
Since the mini origin bar 1) is smaller and 2) looks different from the
scene layer's contents and the Java view will always be visible when
mobar is active, we need to hide it to avoid visual glitches.
Bug: 409317927
Upstream now calls `runCreateFileOnDiskIntent` either way, so this patch becomes obsolete.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/a58bf5281372f484db298f8fcd1c0a8dda0f64a0
[CodeHealth] Clean up LocalPasswordsAndroidAccessLossWarning. Part 1
I've split the cleanup into multiple parts to facilitate the review.
This CL cleans up the code related to password export. It:
1) Enables the feature flag by default in the export flow code.
2) Deletes up ExportWarningDialogFragment that is not used anymore,
and cleans up its tests and strings used only there
3) Deletes PasswordSettingsExportTests, because they test password
export from settings only, and M4.1 export is handled in
PasswordAccessLossExportDialogCoordinatorTest
In the second part I will enable feature by default in other parts of
code.
Change-Id: I233affd3cb8b47cc067a055e92aca219cd5776ef
Chromium change:
https://chromium.googlesource.com/chromium/src/+/c909285bad37c1d74b163429512d5733f628e260
[A11y] Throttle tab closure undo snackbar while tab grid dialog visible
While the tab grid dialog is visible we disable the UndoBarController
and instead use a custom implementation of the UndoBarController in
TabGridDialogMediator to handle the undo snackbar inside the tab grid
dialog. However, when closing all the tabs shown in the tab grid
dialog we still want to show an undo snackbar using the
UndoBarController. As such the disabled state only exists while the
tab grid dialog is fully visible.
Normally this works fine. However, with recent changes to snackbar
accessibility announcements, the animation would clobber the snackbar
announcing its appearance which is a poor user experience.
This CL introduces the ability to throttle the UndoBarController.
While throttled, tab closure events are queued rather than dropped.
When the throttling is stopped all queued events are displayed. If any
tab closure events become obsolete while in the queue they are
removed from the queue.
The throttling interface is built on TokenHolder and allows multiple
concurrent throttles, only releasing when all throttling is ended.
Presently, there is no TTL for events in the queue as it isn't
necessary for the tab grid dialog case as the period in which events
are only throttled and not dropped entirely is only the duration of
an animation which is very short. Moreover, many actions on the
TabModel force clear the queue, such as opening a new tab.
In the future, if throttling is more prevalent we could elect to
implement a TTL for items in the queue to ensure tabs don't remain
in the pending closure state indefinitely. One possible implementation
is to post a delayed task to wipe an event out of the queue X seconds
after it was added.
Fixed: 39592572
Chromium change:
https://chromium.googlesource.com/chromium/src/+/a3b80168e9abfa063071cc10ab487300c708856f
[Toolbar] Moved click/longClick listeners for bookmark and saveOffline buttons to location bar classes.
* Moved onLongClick for saveOffline and bookmark button to LocationBarLayoutTablet since this has simple implementation.
* Moved onClick for saveOffline and bookmark button to LocationBarCoordinator
Change-Id: I4b97d9209fd04f761e93fe393efe7e0d10f6e0b9
Chromium change:
https://chromium.googlesource.com/chromium/src/+/dfdd24a54d2dc4d911e01f58571a34f4dd277ef5
[Toolbar] Move ButtonData classes from chrome.browser.toolbar to chrome.browser.toolbar.optional_button package.
Planning to create new "ToolbarButton*" classes to manage common code for different toolbar buttons and want to avoid naming confusion with optional button code
Bug: 409638002
samartnik
