Sidebar V2 - SidebarContainerViewNew

[simonhong]

Resolves brave/brave-browser#52536

Sidebar V2 is an architectural refactoring that separates the panel management from SidebarContainerView.
This allows Brave to reuse upstream's side panel instead of maintaining a custom brave side panel inside the SidebarContainerView.

No functional change from sidebar control UI.
All behavior should be same except panel open/close. For now, panel open/close doesn't work with V2.

This PR introduces SidebarContainerViewNew and establishes a testing framework to support both V1 and V2 during the migration.

SidebarContainerViewNew Implementation

• New V2 container class: SidebarContainerViewNew
• Replaces the V1 SidebarContainerView with a simplified architecture
• Removes panel management
• Focuses solely on sidebar item UI and control view
• Controlled by kSidebarV2 feature flag

Test Infrastructure for V1/V2 Coexistence

• SidebarBrowserTestParameterized → SidebarBrowserTestV1AndV2
• SidebarContainerViewBrowserTest → SidebarContainerViewBrowserTestV1AndV2
• Tests now run against both V1 and V2 automatically
• Added test categorization framework:
  • Category A: Tests identical in V1/V2 (no conditionals needed)
  • Category B: Mixed tests with version-specific assertions (IsV2Enabled() conditionals)
  • Category C: V1-only tests (use GTEST_SKIP() for V2)
  • Code cleanup:

Migration Strategy:

Parameterized tests allow us to ensure V2 doesn't break existing V1 behavior during the transition. Once V2 is default, tests will be converted back to regular fixtures.

TEST=SidebarBrowserTest*

[github-actions]

_{reported by reviewdog 🐶}
[opengrep] There are several global functions that facilitate dependency inversion. It will not be possible to call them from modularized features (no dependency cycles), and their usage in non-modularized features is considered a red flag

Don't use Browser*. This is functionally a container of hundreds of other pointers. It is impossible to specify dependencies, since Browser* functionally depends on everything. Instead, pass in the relevant pointers, e.g. Profile*, FooFeatureController, etc

References:
- https://chromium.googlesource.com/chromium/src/+/main/docs/chrome_browser_design_principles.md#structure_modularity


Source: https://github.com/brave/security-action/blob/main/assets/opengrep_rules/client/browser-dependency-inversion.yaml


Cc @goodov @cdesouza-chromium @bridiver

[github-actions]

_{reported by reviewdog 🐶}
[opengrep] base::Unretained is most of the time unrequited, and a weak reference is better suited for secure coding.
Consider swapping Unretained for a weak reference.
base::Unretained usage may be acceptable when a callback owner is guaranteed
to be destroyed with the object base::Unretained is pointing to, for example:

- PrefChangeRegistrar
- base::*Timer
- mojo::Receiver
- any other class member destroyed when the class is deallocated


Source: https://github.com/brave/security-action/blob/main/assets/opengrep_rules/client/chromium-uaf.yaml


Cc @thypon @goodov

[github-actions]

_{reported by reviewdog 🐶}
[opengrep] base::Unretained is most of the time unrequited, and a weak reference is better suited for secure coding.
Consider swapping Unretained for a weak reference.
base::Unretained usage may be acceptable when a callback owner is guaranteed
to be destroyed with the object base::Unretained is pointing to, for example:

- PrefChangeRegistrar
- base::*Timer
- mojo::Receiver
- any other class member destroyed when the class is deallocated


Source: https://github.com/brave/security-action/blob/main/assets/opengrep_rules/client/chromium-uaf.yaml


Cc @thypon @goodov

[zeusshomaly]

Parameterized tests allow us to ensure V2 doesn't break existing V1 behavior during the transition. Once V2 is default, tests will be converted back to regular fixtures.

When you say 'Once V2 is default, tests will be converted back to regular fixtures', does that mean adding functions like letting the sidebar apps sync across devices and all that? I thank you for working extremely hard on Web Panel also.

[simonhong]

bar apps sync across de

Well.. this PR is not related with sync. This PR is for refactoring our sidebar implementation.

[zeusshomaly]

bar apps sync across de

Well.. this PR is not related with sync. This PR is for refactoring our sidebar implementation.

Sorry mate. I misread it when I was getting excited about something else.