| Commit-Queue | +1 |
// tabs, so we don't need to do anything here for new browsers.This comment is slightly misleading. `Init()` handles browsers that exist when `Show()` is called. For browsers created after that, the `BrowserTabStripTracker` will observe them and add infobars as needed.
Suggestion:
```cpp
// The BrowserTabStripTracker will handle showing infobars for both existing
// and newly created browsers, so we don't need to do anything here.
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool DefaultBrowserInfoBarManager::ShouldTrackBrowser(could we replace this with DefaultBrowserSurfaceManager::IsBrowserValidForShowing
// BrowserCollectionObserver:
void OnBrowserCreated(BrowserWindowInterface* browser) override;
void OnBrowserClosed(BrowserWindowInterface* browser) override;These should be public, since we're using public inheritance.
bool can_pin_to_taskbar_ = false;Let's make this private and expose a getter method instead, so that child classes cannot modify this. We can consider adding a setter later if needed. Same for `controller_`.
virtual void CloseAllUI() = 0;supernit: "UI" sounds ambiguous: the first question that comes to mind is if this includes all UI for default browser, or just this surface. Perhaps `CloseAllSurfaceInstances` or something like that?
virtual void ShowUIForBrowser(BrowserWindowInterface* browser) = 0;supernit: Show/CloseForBrowser seems sufficient
protected:Are these methods called by any of the derived classes? If not, let's make them private
std::unique_ptr<default_browser::DefaultBrowserController> controller,Could we instead create the controller within this method and destroy it in another method from this class so that the lifecycle is completely encapsulated?
controller_->OnShown();It might be a bit confusing that only a subset of actions are forwarded to the controller, which can skew data if a derived class forgets about the controller.
I think it would be cleaner/more consistent if either this class handles 100% of the interactions with controller (allowing us to hide it from derived classes), or handles none of the interactions. I have a slight preference for the first option, which would behave nicely with my previous comment.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
could we replace this with DefaultBrowserSurfaceManager::IsBrowserValidForShowing
Done
// BrowserCollectionObserver:
void OnBrowserCreated(BrowserWindowInterface* browser) override;
void OnBrowserClosed(BrowserWindowInterface* browser) override;These should be public, since we're using public inheritance.
Done
Let's make this private and expose a getter method instead, so that child classes cannot modify this. We can consider adding a setter later if needed. Same for `controller_`.
Done
supernit: "UI" sounds ambiguous: the first question that comes to mind is if this includes all UI for default browser, or just this surface. Perhaps `CloseAllSurfaceInstances` or something like that?
Done
virtual void ShowUIForBrowser(BrowserWindowInterface* browser) = 0;Foromo Daniel Soromousupernit: Show/CloseForBrowser seems sufficient
Done
protected:Are these methods called by any of the derived classes? If not, let's make them private
They are implemented by the derived classes. That is why it should be at least protected since derived classes cannot implement private methods from parent class.
std::unique_ptr<default_browser::DefaultBrowserController> controller,Could we instead create the controller within this method and destroy it in another method from this class so that the lifecycle is completely encapsulated?
Done
It might be a bit confusing that only a subset of actions are forwarded to the controller, which can skew data if a derived class forgets about the controller.
I think it would be cleaner/more consistent if either this class handles 100% of the interactions with controller (allowing us to hide it from derived classes), or handles none of the interactions. I have a slight preference for the first option, which would behave nicely with my previous comment.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm % making the pure virtual methods private
protected:Foromo Daniel SoromouAre these methods called by any of the derived classes? If not, let's make them private
They are implemented by the derived classes. That is why it should be at least protected since derived classes cannot implement private methods from parent class.
Child classes can implement private methods from the parent class. By making it private, we're essentially saying "the child class should implement this, but only the base class will invoke it".
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
protected:Foromo Daniel SoromouAre these methods called by any of the derived classes? If not, let's make them private
Kaan AlsanThey are implemented by the derived classes. That is why it should be at least protected since derived classes cannot implement private methods from parent class.
Child classes can implement private methods from the parent class. By making it private, we're essentially saying "the child class should implement this, but only the base class will invoke it".
Oh got it, Thank you for the clarification.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
10 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/browser/ui/startup/default_browser_prompt/default_browser_surface_manager.h
Insertions: 10, Deletions: 10.
@@ -49,6 +49,16 @@
bool can_pin_to_taskbar() const { return can_pin_to_taskbar_; }
protected:
+ // Helper function to determine if a browser window is suitable for showing a
+ // prompt. Excludes incognito, guest, and non-normal browser windows.
+ bool IsBrowserValidForShowing(BrowserWindowInterface* browser);
+
+ // Methods for derived classes to handle user interactions via the controller.
+ void HandleAccept();
+ void HandleDismiss();
+ void HandleIgnore();
+
+ private:
// Abstract methods to be implemented by subclasses to handle UI operations.
//
// Shows the specific prompt UI for the given browser window.
@@ -60,16 +70,6 @@
// Closes all prompt instances managed by the subclass.
virtual void CloseAllPromptInstances() = 0;
- // Helper function to determine if a browser window is suitable for showing a
- // prompt. Excludes incognito, guest, and non-normal browser windows.
- bool IsBrowserValidForShowing(BrowserWindowInterface* browser);
-
- // Methods for derived classes to handle user interactions via the controller.
- void HandleAccept();
- void HandleDismiss();
- void HandleIgnore();
-
- private:
// Flag indicating if the taskbar pinning option should be available.
bool can_pin_to_taskbar_ = false;
```
Consolidate common logic in DefaultBrowserSurfaceManager
This refactoring transforms `DefaultBrowserSurfaceManager` from an
interface into an abstract base class to handle shared functionality for
different default browser prompt types.
Previously, `DefaultBrowserBubbleDialogManager` and
`DefaultBrowserInfoBarManager` duplicated logic for observing browser
window creation and destruction, managing the
`DefaultBrowserController`, and tracking the `can_pin_to_taskbar` state.
With the upcoming `DefaultBrowserModalDialogManager` more code will be
duplicated.
This change centralizes that logic within the base class by:
* Moving `BrowserCollectionObserver` inheritance and related lifecycle
management to `DefaultBrowserSurfaceManager`.
* Providing a shared `IsBrowserValidForShowing` helper to exclude
incognito, guest, and non-normal browser windows consistently.
* Introducing abstract methods (`ShowUIForBrowser`,
`CloseUIForBrowser`, and `CloseAllUI`) that subclasses must
implement for their specific UI presentation logic.
Consolidating this logic reduces code duplication and simplifies the
concrete implementations, ensuring a unified approach to displaying
default browser prompts across the application.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |