chromiumembedded / cef

Chromium Embedded Framework (CEF). A simple framework for embedding Chromium-based browsers in other applications.
https://bitbucket.org/chromiumembedded/cef/
Other
3.35k stars 467 forks source link

chrome: Improve "Find" widget position with hidden frame #3461

Closed magreenblatt closed 1 year ago

magreenblatt commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago
magreenblatt commented 1 year ago

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

magreenblatt commented 1 year ago

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)

image