BrowserWindowFeatures Ordering

BrowserWindowFeatures ordering is intentionally structured. Preserve the current layout when adding or moving feature ownership.

Public Header

In browser_window_features.h:

• Forward-declare feature controller and dependency types in the header; do not #include their headers here. std::unique_ptr<T> and raw_ptr<T> members only need a forward declaration of T, so add class FooController; to the forward-declaration block and put the controller's #include in browser_window_features.cc instead. This keeps the aggregator header dependency-light. When you add a new BWF-owned controller, follow the existing pattern in the file rather than including the new controller's header.
• Keep top-level forward declarations sorted alphabetically within their existing unconditional group.
• Keep platform-conditional forward declarations sorted within each buildflag group.
• Keep namespaced forward declarations sorted by namespace and class within the existing namespace sections.
• Keep public inline accessors sorted by accessor name unless an existing local comment explains a special case.
• Do not add a public accessor by default. Prefer UnownedUserData for new feature access.

Private Members

Do not mechanically alphabetize private members. Declaration order controls destruction order, so changes require dependency review.

Private members are grouped by ownership:

1. members owned by all browser window types;
2. members owned only when a BrowserView is attached;
3. members owned only when a WebUIBrowserWindow is used;
4. platform-specific members;
5. non-owning references;
6. embedder features last.

Within a group, keep related dependency clusters together. If a member must be out of alphabetical position, add or preserve a Must be before or Must be after comment.

New BWF-owned controllers must make their dependencies explicit when ordering matters. Construct them through GetUserDataFactory().CreateInstance<FooController>(*browser, ...) (which returns a std::unique_ptr<>), not std::make_unique. Put the dependency comment next to the member declaration or the initialization site, following the local style:

// Must be after session_service_browser_helper_:
//   tab_list_bridge_ depends on initialized session tab/window state.
tab_list_bridge_ =
    GetUserDataFactory().CreateInstance<TabListBridge>(*browser, ...);

For a new FooWindowController, call out both directions when relevant:

• what foo_window_controller_ depends on;
• what later BWF feature depends on foo_window_controller_ being initialized.

Lifecycle Methods

The three lifecycle methods follow a consistent layout:

1. A short prelude captures shared locals and foundational state.
2. Members owned by all browser window types.
3. Members owned only by TYPE_NORMAL browser windows.
4. Embedder features are initialized last.

Dependency ordering takes precedence over alphabetical ordering. Important ordering constraints should be called out inline.

Teardown

TearDownPreBrowserWindowDestruction() tears down in reverse order of the construction lifecycle:

1. embedder features;
2. InitPostWindowConstruction() members;
3. Init() members.

Within each section, reset members in reverse of the corresponding initialization order unless a dependency comment explains a different order.