chrome/browser/ui/views/frame/README.md
Each browser window has the same structure, depicted below:
NativeWidget.BrowserViewLayoutDelegate.
BrowserViewLayout retrieves information
about the layout. Implemented by BrowserView; designed to be able
to be mocked.┌─────────────────────────────────────┐ ┌───────────────────────┐
│ BrowserWidget │ ↔ │ BrowserNativeWidget + │
│ ┌─────────────────────────────────┐ │ │ NativeWidget │
│ │ RootView │ │ └───────────────────────┘
│ │ ┌─────────────────────────────┐ │ │
│ │ │ NonClientView │ │ │
│ │ │ ┌─────────────────────────┐ │ │ │
│ │ │ │ BrowserFrameView | │ │ │
│ │ │ │ ┌─────────────────────┐ │ │ │ │
│ │ │ │ │ BrowserView │ │ │ │ │
│ │ │ │ │ (ClientView) │ │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ │ └─────────────────────┘ │ │ │ │
│ │ │ └─────────────────────────┘ │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────┘
If you're not sure where some piece of functionality goes:
Anything relating to the content of the browser window goes in BrowserView.
BrowserViewLayout.Anything relating to the frame and titlebar of the browser window goes in
BrowserFrameView, including but not limited to:
Any information or features of the whole window that are platform-specific go
in BrowserNativeWidget and are implemented in its platform-specific
subclasses.
Any views::Widget-specific stuff, like window event handling, goes in
BrowserWidget
BrowserNativeWidget.Cross-desktop-platform code should have access to BrowserView,
BrowserWidget, BrowserFrameView, and BrowserNativeWidget. Therefore it is
not necessary to pipe calls through another class if the class that actually has
the method in question is available.
(The one exception is BrowserViewLayout, which has access only to
BrowserViewLayoutDelegate, so calls must be piped through that class.)
Platform-specific logic should be behind a platform-agnostic API when possible,
and if it actually applies to multiple platforms. If there is a logic path that
only applies to one platform, try to encapsulate it in a platform-specific
implementation; if it absolutely must be referenced outside of that
implementation, place any required references in #if BUILDFLAG() blocks.
For example, BrowserFrameView::CaptionButtonsOnLeadingEdge() is a general
question one might ask about any browser frame - "are the caption buttons on
the leading (vs. trailing) edge of the window?" since caption buttons are
present on every desktop platform, and it is used in cross-platform code.
Therefore it goes in BrowserFrameView, and should be called directly if that
information is needed.
On the other hand, GetMinimizeButtonOffset() lives in BrowserFrameViewWin
not because it's a question that could be asked about any browser, but is only
ever actually used on Windows. It's an implementation detail that doesn't need
to be in the general interface.