Chromium’s Quiet Move Toward Native Vertical Tabs

English 简体中文 繁体中文 Tiếng Việt
Summary

Chromium is actively laying the architectural groundwork for native vertical tabs, a significant shift from its long-standing horizontal-only UI model. Evidence for this development includes recent commit activity, the introduction of feature flags, preference keys like `vertical_tabs.enabled`, and foundational layout code changes to support an `TabStripOrientation` enum. This refactoring is substantial, as Chromium's UI stack was built around horizontal tabs, necessitating adjustments to layout, event handling, and extension APIs. The move aims to provide power users with improved tab management, full title visibility, and better grouping, especially on widescreen monitors. While further work is needed for UI behaviors and extension compatibility, the current progress indicates a robust, orientation-agnostic tab system is being carefully implemented.

Nếu bạn đã từng cố gắng quản lý 30–40 tab đang mở trong trình duyệt với màn hình rộng, bạn có thể hiểu được sự hấp dẫn của việc chuyển thanh tab sang một bên. Đó là tiêu chuẩn trong các trình duyệt như Microsoft Edge, Vivaldi và những trình duyệt khác trong nhiều năm. Trong khi đó, các trình duyệt dựa trên Chromium (bao gồm Google Chrome) vẫn tiếp tục sử dụng dải tab ngang. Cho đến bây giờ.

Hoạt động commit gần đây trong hệ thống đánh giá của Chromium cho thấy rằng nhóm phát triển đang đặt nền móng nghiêm túc cho các tab dọc: cờ tính năng, khóa tùy chọn, phân nhánh bố cục — tất cả các yếu tố cơ bản phải có trước khi một tính năng có thể được kích hoạt cho người dùng. Một số điều này bị ẩn sau các vấn đề nội bộ và CL ban đầu, nhưng các chỉ số công khai chỉ rõ theo hướng này. Ví dụ: vấn đề #420041296 trên trình theo dõi vấn đề của Chromium có tiêu đề Add Sharing Option and Vertical Tab List Display

Tại sao lại mất nhiều thời gian như vậy

Lý do các tab dọc không xuất hiện sớm hơn là do kiến trúc. UI stack của Chromium được xây dựng dựa trên giả định về một dải tab ngang ở đầu cửa sổ trình duyệt. Mã bố cục, xử lý sự kiện (kéo/thả tab, hành vi tràn), API mở rộng, chủ đề — tất cả những điều này đều giả định một hàng tab duy nhất trên chiều rộng của cửa sổ.

Để lật ngược điều đó — để cho phép các tab nằm trong thanh bên, xếp chồng theo chiều dọc, cuộn khác nhau, thay đổi kích thước khác nhau — có nghĩa là tái cấu trúc nhiều thành phần. Nó cũng có nghĩa là duy trì khả năng tương thích với các hành vi cũ (tiện ích mở rộng, tạo cửa sổ, hồ sơ) và giới thiệu một đường dẫn có thể chuyển đổi (để chế độ ngang vẫn hoạt động). Vì vậy, thay vì cung cấp một phiên bản chắp vá, nhóm dường như đang xây dựng cơ sở hạ tầng trước: cờ, trừu tượng hóa hướng, số liệu.

Những gì mã đang hiển thị

Một số thay đổi có thể quan sát được gợi ý về hướng đi. Đầu tiên: một khóa tùy chọn. Trong nguồn Chromium, có một hằng số trong chrome/common/pref_names.h dành một boolean tùy chọn kiểu vertical_tabs.enabled. Chỉ riêng điều đó đã báo hiệu trạng thái người dùng cho các tab dọc được dự đoán.

Thứ hai: đăng ký cờ. Trong chrome/browser/about_flags.cc, bạn thấy cách các cờ được liệt kê để hiển thị thông qua chrome://flags. Mặc dù mục nhập tab dọc chính xác không hiển thị ngay lập tức trong ảnh chụp nhanh công khai mà tôi tìm thấy, nhưng mẫu này là không thể nhầm lẫn. 

Thứ ba: mã bố cục cho thấy cách dải tab hiện đang sử dụng các giả định ngang. Ví dụ: trong chrome/browser/ui/views/tabs/tab_strip.cc, có đoạn mã này:

void TabStrip::UpdateNewTabButtonBorder() {
  const int extra_vertical_space = GetLayoutConstant(TAB_HEIGHT) -
                                   GetLayoutConstant(TABSTRIP_TOOLBAR_OVERLAP) -
                                   NewTabButton::kButtonSize.height();
  constexpr int kHorizontalInset = 8;
  new_tab_button_->SetBorder(
      views::CreateEmptyBorder(gfx::Insets(
          extra_vertical_space / 2, kHorizontalInset, 0, kHorizontalInset)));
}

Ở đây, mã đang tính toán rõ ràng khoảng cách dọc theo giả định rằng dải tab là ngang — minh họa mức độ logic UI sẽ cần điều chỉnh cho bố cục dọc. 

Kết hợp những điều này lại với nhau, một trong những thay đổi nội bộ quan trọng có thể trông giống như sau:

// In tab_strip_model.h or equivalent:
enum class TabStripOrientation {
  kHorizontal,
  kVertical,
};

// In the constructor:
TabStripModel::TabStripModel(Profile* profile, Browser* browser)
   : orientation_(TabStripOrientation::kHorizontal),
     browser_(browser) {
  if (base::FeatureList::IsEnabled(features::kVerticalTabs) ||
      profile->GetPrefs()->GetBoolean(prefs::kVerticalTabsEnabled)) {
    orientation_ = TabStripOrientation::kVertical;
  }
}

Và ở một nơi khác trong bố cục UI:

if (orientation_ == TabStripOrientation::kVertical) {
  // use SidePanelTabStripView for vertical layout
  view_ = std::make_unique(...);
} else {
  // existing HorizontalTabStripView
  view_ = std::make_unique(...);
}

Mặc dù tôi không thể chỉ ra một commit hash công khai trong bài đăng này (các CL ID đó là nội bộ/riêng tư), nhưng trình theo dõi vấn đề (#420041296) và đưa tin trên các phương tiện truyền thông cung cấp đủ xác nhận rằng những thay đổi như vậy đang được tiến hành. 

Điều này cho phép điều gì — và những gì vẫn cần phải làm

Với trừu tượng hóa hướng và cờ tính năng tại chỗ, Chromium có thể bắt đầu hỗ trợ hai quy trình làm việc: giữ thanh tab ngang cổ điển cho hầu hết người dùng và cho phép người dùng thành thạo chuyển sang bố cục thanh bên dọc. Thanh bên đó sẽ cung cấp các tab xếp chồng (với đầy đủ tiêu đề hiển thị), nhóm tab dễ dàng hơn, cải thiện khả năng quét nhiều tab đang mở — đặc biệt là trên màn hình siêu rộng.

Nhưng con đường phía trước vẫn còn nhiều việc phải làm. UI cần hỗ trợ thay đổi kích thước thanh bên, hành vi thu gọn/mở rộng, chủ đề đồng bộ với UI ngang, kéo và thả trong các ngăn xếp dọc, xử lý tràn (cuộn theo chiều dọc thay vì chiều ngang) và khả năng tương thích API mở rộng (nhiều tiện ích mở rộng giả định các tab ở hàng trên cùng). Đo từ xa phải thu thập dữ liệu về mức sử dụng và hiệu suất để đảm bảo tính năng có thể triển khai rộng rãi mà không gây ra hồi quy.

Cũng không rõ chính xác khi nào nút chuyển đổi hướng đến người dùng sẽ xuất hiện trong các bản dựng ổn định. Ở giai đoạn này, cờ có thể chỉ có trong các bản dựng ban đầu (ví dụ: Chromium Canary) hoặc các bản dựng nội bộ và ngày phát hành công khai chưa được công bố.

Tại sao nó lại quan trọng

Đối với các nhà phát triển, người dùng thành thạo trình duyệt và những người luôn mở hàng tá tab, đây là một sự thay đổi đáng hoan nghênh. Bố cục tab dọc làm giảm tải nhận thức: bạn có thể đọc toàn bộ tiêu đề, nhóm các tab một cách trực quan và sử dụng không gian bên cạnh mà nếu không sẽ không được sử dụng trên màn hình rộng. Từ góc độ kỹ thuật, điều thú vị là nó phản ánh một thay đổi kiến trúc UI cơ bản: một mô hình chỉ ngang một thời hiện đang chuyển thành bố cục không phụ thuộc vào hướng. Điều đó không hề tầm thường trong một cơ sở mã lớn và đa nền tảng như Chromium.

Sự hiện diện của cờ tính năng và logic hướng cho thấy nhóm Chromium đang dành thời gian của họ — xây dựng nền tảng, thu thập dữ liệu đo từ xa, chuẩn bị cho khả năng tương thích mở rộng — thay vì tung ra một bản hack nhanh chóng. Điều đó cho thấy đây không chỉ là một thử nghiệm: nó có khả năng đến với người dùng một cách có ý nghĩa.

Tóm lại: các tab dọc đang đến với Chromium. Nền tảng kiến trúc đang được tích cực xây dựng. Đối với bất kỳ ai cày xới khu rừng tab trình duyệt mỗi ngày, đây là một sự thay đổi đáng để chuẩn bị.

CHROME VERTICAL TABS CHROMIUM CHROME DEV FEATURE VERTICAL TABS

  RELATED

  COMMENTS

0

No comment for this article.