search

chromiumembedded / cef

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

Dropdowns are hidden behind browser window, if the window changes to top-most (WS_EX_TOPMOST style) #2860

Open magreenblatt opened 4 years ago

magreenblatt commented 4 years ago

Original report by Matthias Dittrich (Bitbucket: Matthias Dittrich).

This is basically a continuation of #1468/dropdowns-are-hidden-behind-browser-window

What steps will reproduce the problem?

But instead of starting the application in topmost you do the following:

  1. Start cef_binary_79.1.10+g7ec49fa+chromium-79.0.3945.117_windows64_client
  2. Open https://www.nirsoft.net/utils/gui_prop_view.html from Nirsoft and find the window
  3. Right Click → Top Most Switch
  4. Dropdowns are hidden from this point on

Our Application can change TopMost at runtime.

Please provide any additional information below.

Given the previous patch I’m trying to find a workaround/patch for this, but the build infrastructure is a bit overwhelming, so I decided to just report the issue and see if somebody can help.

We use CefSharp (https://github.com/cefsharp/CefSharp) but the issue is completely reproducible for me on the cef_binary.

There is a related “unresolved” issue https://github.com/cefsharp/CefSharp/issues/657 which I wanted to debug/fix as well but being unable to debug into CEF itself makes that hard. I feel like this is actually related as in Multi-Threading enabled the initialization order might be different (so my assumption is the parent window is added to late for the top-most to be picked up)

The only “difference” between the working and the not-working runtime flags I found was this:

In a non-working run it looks like this:

The interesting thing is that the TOPMOST style is not actually a valid style for child-windows. So I’m not sure how chromium actually achieves that state. I feel like there is still some deeper issue here.

To find a workaround, I tried setting that style via SetWindowLongPtrGWL_EXSTYLE and GWL_STYLE as well as SetWindowPoson that particular WidgetWin_0handle. But no call changes the behavior.

Additionally, I noticed that chrome itself doesn’t have this problem.

Any help is appreciated, I’m happy to send a PR. However, I still feel like I have not understood the root cause and I’m still fighting with the build infrastructure.

‌

magreenblatt commented 4 years ago

Original comment by Matthias Dittrich (Bitbucket: Matthias Dittrich).

One more comment for an obvious “quick fix”:

Is there a reason why the logic in https://bitbucket.org/chromiumembedded/cef/commits/5969b2b was added conditionally? My assumption is that if we just always assume true there it would work “as expected”. This is because if you start the sample with --always-on-top it seems to work as expected, even when you change the TopMost flag with gui_prop_view at runtime.