RTL: Application bar is not rendered right-to-left when using Windows with an RTL language

[dancarroll]

Describe the bug CEF application window renders incorrectly when Windows is set to an right-to-left (RTL) display language, such as Arabic. I would expect the entire application bar to be reversed (close/maximize/minimize on the left side), but it remains left-to-right.

I am using the Views framework to create the top-level window. CefSettings.locale and CefSettings.accept_language_list are both set to "ar" prior to calling CefInitialize. The main window is being created using CefBrowserView::CreateBrowserView and CefWindow::CreateTopLevelWindow.

To Reproduce Steps to reproduce the behavior:

1. Change Windows display language setting to "Arabic (Saudi Arabia)"
   1. Windows Settings -> Time & Language -> Language -> Windows display language
2. Log out and back into your Windows account
3. Launch the CEF sample application, with Views framework enabled: cefclient.exe --use-views

Expected behavior Entire application bar to be reversed (close/maximize/minimize on the left side)

Screenshots Screenshots attached comparing Chromium, Notepad, and CEF sample app. Two screenshots show using the CEF sample app with no arguments, --use-views, and --enable-chrome-runtime

Versions (please complete the following information):

• OS: Windows 10 22H2 (19045.3448)
• CEF Version: 117.2.4

Additional context Does the problem reproduce with the cefclient or cefsimple sample application at the same version? Yes

Does the problem reproduce with Google Chrome at the same version? No

[dancarroll]

CEF forum discussion prior to opening the bug: https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=19576

[magreenblatt]

Works as expected in cefsimple (M121):

> cefsimple.exe --enable-chrome-runtime --lang=he

[magreenblatt]

Chrome UI custom draws the windows caption buttons via WindowsCaptionButton::GetButtonDisplayOrderIndex, which handles RTL.

CEF Views, on the other hand, uses the default OS-drawn windows caption. We'll need to figure out if or how Windows supports per-application RTL configuration of windows caption drawing.

[magreenblatt]

From https://forum.qt.io/post/71185:

In Microsoft Windows, you have to set the WS_EX_LAYOUTRTL | WS_EX_NOINHERITLAYOUT extended window style flags.

[magreenblatt]

Chromium provides a l10n_util::GetExtendedTooltipStyles function that is called called from CalculateWindowStylesFromInitParams when Widget::InitParams::mirror_origin_in_rtl is true.

Setting Widget::InitParams::mirror_origin_in_rtl appears to be the best option, as adding WS_EX_LAYOUTRTL unconditionally breaks the Chrome UI frame.

[magreenblatt]

Setting Widget::InitParams::mirror_origin_in_rtl appears to be the best option, as adding WS_EX_LAYOUTRTL unconditionally breaks the Chrome UI frame.

Nope, that breaks Chrome's internal hit testing and menu placement calculations.

[magreenblatt]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1515385 to track this on the Chromium side.

[magreenblatt]

Here's the change to test mirror_origin_in_rtl behavior with CEF:

diff --git libcef/browser/views/window_view.cc libcef/browser/views/window_view.cc
index 2d12d1964..719447198 100644
--- libcef/browser/views/window_view.cc
+++ libcef/browser/views/window_view.cc
@@ -516,6 +516,10 @@ void CefWindowView::CreateWidget(gfx::AcceleratedWidget parent_widget) {
     // Don't show the native window caption. Setting this value on Linux will
     // result in window resize artifacts.
     params.remove_standard_frame = true;
+  } else if (!has_native_parent) {
+    // Adds WS_EX_LAYOUTRTL if an RTL locale is configured. This supports correct
+    // ordering of OS-rendered windows caption buttons.
+    params.mirror_origin_in_rtl = true;
   }
 #endif

[magreenblatt]

The likely fix for this issue with Views and Chrome Runtime will be a custom-drawn frame similar to how Chrome UI works currently.