chrome: Improve "Find" widget position with hidden frame

[magreenblatt]

Original report by me.

---

What steps will reproduce the problem?

1. Run cefclient --enable-chrome-runtime --hide-frame --hide-controls
2. Show the “Find” widget (Ctrl+F or select “Find…” from 3-dot menu)

What is the expected output? What do you see instead?

The “Find” widget should appear below the overlay controls. Instead, it appears on top of the overlay controls.

Additional related problems:

• Resizing the window causes the overlay to appear on top of the “Find” widget (and it remains on top thereafter)
• If the “Find” widget intersects a draggable region (webkit-app-region), that portion of the widget cannot be clicked

What version of the product are you using? On what operating system?

M112 on Windows 10 64-bit.

To resolve these issues, the client should be able to:

1. Provide insets for “Find” widget position (to avoid intersecting other controls such as overlays in the window).
2. Retrieve the current “Find” widget position, if visible (to use for adjusting draggable regions).

‌

[magreenblatt]

Bounds are calculated in ToolbarView::GetFindBarBoundingBox

>	libcef.dll!ToolbarView::GetFindBarBoundingBox(int contents_bottom) Line 816	C++
 	libcef.dll!BrowserView::GetFindBarBoundingBox() Line 1161	C++
 	libcef.dll!FindBarHost::GetWidgetBounds(gfx::Rect * bounds) Line 417	C++
 	libcef.dll!FindBarHost::GetDialogPosition(gfx::Rect avoid_overlapping_rect) Line 361	C++
 	libcef.dll!DropdownBarHost::Show(bool animate) Line 113	C++
 	libcef.dll!FindBarHost::Show(bool animate) Line 181	C++
 	[External Code]	
 	libcef.dll!FindBarController::Show(bool find_next, bool forward_direction) Line 50	C++
 	libcef.dll!chrome::FindInPage(Browser * browser, bool find_next, bool forward_direction) Line 1514	C++
 	libcef.dll!chrome::Find(Browser * browser) Line 1499	C++
 	libcef.dll!chrome::BrowserCommandController::ExecuteCommandWithDisposition(int id, WindowOpenDisposition disposition, base::TimeTicks time_stamp) Line 668	C++
 	libcef.dll!chrome::BrowserCommandController::ExecuteCommand(int id, base::TimeTicks time_stamp) Line 378	C++
 	libcef.dll!chrome::ExecuteCommand(Browser * browser, int command, base::TimeTicks time_stamp) Line 447	C++

It’s likely possible to perform these calculations internally, at least for inputs such as overlays, draggable regions and toolbar height (for macOS).

[magreenblatt]

Expected placement behavior on Windows:

cefclient.exe --enable-chrome-runtime (under toolbar)

‌

cefclient.exe --enable-chrome-runtime --hide-frame (under toolbar and draggable region)

‌

cefclient.exe --enable-chrome-runtime --hide-frame --hide-controls (under toolbar overlay which overlaps draggable region)

‌

cefclient.exe --enable-chrome-runtime --hide-frame --hide-controls --hide-overlays (under draggable region)

‌

cefclient.exe --enable-chrome-runtime --hide-frame --hide-controls --hide-overlays --url=https://google.com (top of window)

‌

[magreenblatt]

• changed title from "chrome: Allow configuration of "Find" widget position with hidden frame" to "chrome: Improve "Find" widget position with hidden frame"

[magreenblatt]

Fixing this for MacOS is blocked on #3462 and #3456

[magreenblatt]

Positional behavior on macOS should be the same as Windows for the above examples.

On macOS we also have --show-window-buttons to show the traffic light buttons on a frameless window. It should have the same positional behavior as --hide-frame alone, except in this one case:

cefclient --enable-chrome-runtime --hide-frame --hide-controls --hide-overlays --url=http://google.com --show-window-buttons (under the traffic light buttons)