Closed magreenblatt closed 3 years ago
Comment 1. originally posted by magreenblatt on 2014-02-18T19:53:11.000Z:
Original comment by Anonymous.
Comment 3. originally posted by norbertk237 on 2014-03-30T10:41:05.000Z:
I created a fix for this with jQuery. I still need to add styling to look exactly like the built-in version. https://github.com/norbertkeresztes/cef-dropdown-fix
Comment 4. originally posted by magreenblatt on 2014-04-10T15:49:46.000Z:
issue #1250 has been merged into this issue.
Comment 5. originally posted by magreenblatt on 2014-05-06T15:19:18.000Z:
issue #1269 has been merged into this issue.
Original comment by Anonymous.
Comment 6. originally posted by gchiocchio on 2014-05-07T11:31:10.000Z:
simply but not beautiful workaround is add wm_move to cefclient with this code:
case WM\_MOVE:
if (g\_handler.get() && g\_handler->GetBrowser()) {
// Pass focus to the browser window
CefWindowHandle hwnd =
g\_handler->GetBrowser()->GetHost()->GetWindowHandle();
RECT rect;
GetClientRect(hWnd, &rect);
HDWP hdwp = BeginDeferWindowPos(1);
hdwp = DeferWindowPos(hdwp, hwnd, NULL,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top+1,
SWP\_NOZORDER);
EndDeferWindowPos(hdwp);
HDWP hdwp2 = BeginDeferWindowPos(1);
hdwp2 = DeferWindowPos(hdwp2, hwnd, NULL,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
SWP\_NOZORDER);
EndDeferWindowPos(hdwp2);
}
return TRUE;
Original comment by Dragan Grbic (Bitbucket: Dragan Grbic).
Comment 7. originally posted by dgrbic on 2014-06-23T11:40:03.000Z:
I've changed previous fix, as it results in non smooth moving of window
// Fix for dropdown moving - Callback for EnumChildWindows
BOOL CALLBACK EnumWndProc(HWND hWnd, LPARAM lParam)
{
PostMessage(hWnd, WM_KILLFOCUS, NULL, NULL);
return TRUE;
}
... and in main window message processing...
case WM_MOVE:
if (g_handler.get() && g_handler->GetBrowser()) {
CefWindowHandle hwnd = g_handler->GetBrowser()->GetHost()->GetWindowHandle();
if (hwnd) EnumChildWindows(hwnd, EnumWndProc, NULL);
}
return TRUE;
Original comment by Anonymous.
Comment 9. originally posted by ryan.goat on 2014-06-30T11:24:54.000Z:
Yes, I just confirmed it is still present.
I used the following . . .
cefbuilds.com Windows 32bit 2014-06-26 CEF 3.2043.1750
MS visual studio 2013
Original comment by Anonymous.
Comment 10. originally posted by egor.ivanitsky on 2014-08-28T07:06:12.000Z:
After investigating that problem, it looks like we somehow have to call RenderWidgetHostImpl::SendScreenRects() after moving window. Renderer send message ViewHostMsg_ShowWidget for showing HTMLSelect element, with wrong coordinates because it doesn't know that window has been moved.
I've temporarily solved this problem by creating method in CefBrowserHost in which I call SendScreenRects(), and then call this method from WM_MOVE handler in main window.
Original comment by Anonymous.
Comment 11. originally posted by slobodan.a.ilic on 2014-09-07T09:35:43.000Z:
The workaround that I found working, upon improving on one of the previous fixes, is to redraw the window on WM_EXITSIZEMOVE event, like this:
case WM_EXITSIZEMOVE:
if (g_handler.get() && g_handler->GetBrowser()) {
// Pass focus to the browser window
CefWindowHandle hwnd =
g_handler->GetBrowser()->GetHost()->GetWindowHandle();
RECT rect;
GetClientRect(hWnd, &rect);
HDWP hdwp = BeginDeferWindowPos(1);
hdwp = DeferWindowPos(hdwp, hwnd, NULL,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top + 1,
SWP_NOZORDER);
EndDeferWindowPos(hdwp);
HDWP hdwp2 = BeginDeferWindowPos(1);
hdwp2 = DeferWindowPos(hdwp2, hwnd, NULL,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
SWP\_NOZORDER);
EndDeferWindowPos(hdwp2);
}
return TRUE;
This is the same code as the previous fix, but it only occurs once, and doesn't introduce the problem of non-smooth window moving.
Original comment by Anonymous.
Comment 12. originally posted by jcmayhew on 2014-09-18T23:33:06.000Z:
That is a great workaround. Anyone thought of one for Linux?
Original comment by Anonymous.
Comment 13. originally posted by jcmayhew on 2014-09-19T00:01:02.000Z:
Okay, I may have a workaround for Linux. I'll test it some more and post it tomorrow morning.
Original comment by Anonymous.
Comment 14. originally posted by jmayhew@google.com on 2014-09-19T17:53:39.000Z:
The linux fix is pretty much the same as what slobodan did for Windows. When the main window is moved/sized, you fake a quick size operation to force the required updates.
My handler for the "size-allocate" signal is basically exactly like the one in CefClient
void VboxSizeAllocated(GtkWidget* /*widget*/,
GtkAllocation* allocation,
void* /*data*/) {
if (g_cef_client) {
CefRefPtr
if (browser && !browser->GetHost()->IsWindowRenderingDisabled()) {
// Size the browser window to match the GTK widget.
::Display* xdisplay = cef_get_xdisplay();
::Window xwindow = browser->GetHost()->GetWindowHandle();
XWindowChanges changes = {0};
changes.width = allocation->width;
changes.height = allocation->height - g_toolbar_height;
XConfigureWindow(xdisplay, xwindow, CWHeight | CWWidth, &changes);
}
}
}
To force the resize after a move add a signal handler for "configure-event" as follows
g_signal_connect(g_main_window, "configure-event", G_CALLBACK(OnWindowResize), 0);
This handler will be called after every main window move or size operation. It is only called once when the operation ends.
In your handler fake two calls to VboxSizeAllocated() as follows
boolean OnWindowResize(GtkWindow* window, GdkEventConfigure* event,
gpointer data) {
if (event) {
// Force a slight resize to fix dropdown placement issue.
GtkAllocation temp;
temp.width = event->width;
temp.height = event->height + 1;
VboxSizeAllocated(NULL, &temp, NULL);
temp.height = event->height;
VboxSizeAllocated(NULL, &temp, NULL);
}
}
Original comment by Anonymous.
Comment 15. originally posted by ryan.goat on 2014-09-26T15:43:27.000Z:
Here is my version of the workaround in comment comment 11.. It improves on comment 11. by closing any open select elements when you begin moving the window and only uses one deferred window position sequence.
case WM_ENTERSIZEMOVE:
case WM_EXITSIZEMOVE:
if (g_handler.get() && g_handler->GetBrowser()) {
// Pass focus to the browser window
CefWindowHandle hwnd =
g_handler->GetBrowser()->GetHost()->GetWindowHandle();
RECT rect;
GetClientRect(hWnd, &rect);
HDWP hdwp = BeginDeferWindowPos(1);
hdwp = DeferWindowPos(hdwp, hwnd, NULL,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top + 1,
SWP\_NOZORDER);
hdwp = DeferWindowPos(hdwp, hwnd, NULL,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
SWP\_NOZORDER);
EndDeferWindowPos(hdwp);
}
return TRUE;
Original comment by Anonymous.
Comment 16. originally posted by slobodan.a.ilic on 2014-09-26T16:07:39.000Z:
Great, thanks :)
Comment 17. originally posted by magreenblatt on 2014-10-14T14:28:40.000Z:
Related comments: http://magpcss.org/ceforum/viewtopic.php?f=6&t=11503\#p22484
Comment 18. originally posted by magreenblatt on 2014-10-28T15:40:10.000Z:
The RenderWidgetHostImpl::SendScreenRects() method needs to be called when the window is moved or resized. In Chrome (revision d075289 (bb)) on Windows the call stacks are as follows:
WM_MOVING message:
chrome.dll!content::RenderWidgetHostImpl::SendScreenRects() Line 370 C++
chrome.dll!content::WebContentsViewAura::WindowObserver::SendScreenRects() Line 683 C++
chrome.dll!content::WebContentsViewAura::WindowObserver::OnHostMoved(const aura::WindowTreeHost * host, const gfx::Point & new_origin) Line 677 C++
chrome.dll!aura::WindowTreeHost::OnHostMoved(const gfx::Point & new_location) Line 231 C++
chrome.dll!views::DesktopWindowTreeHostWin::HandleMove() Line 796 C++
chrome.dll!views::HWNDMessageHandler::OnMoving(unsigned int param, const tagRECT * new_bounds) Line 1586 C++
chrome.dll!views::HWNDMessageHandler::_ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam, long & lResult, unsigned long dwMsgMapID) Line 390 C++
chrome.dll!views::HWNDMessageHandler::OnWndProc(unsigned int message, unsigned int w_param, long l_param) Line 924 C++
WM_WINDOWPOSCHANGED message:
chrome.dll!content::RenderWidgetHostImpl::SendScreenRects() Line 370 C++
chrome.dll!content::WebContentsViewAura::WindowObserver::SendScreenRects() Line 683 C++
chrome.dll!content::WebContentsViewAura::WindowObserver::OnWindowBoundsChanged(aura::Window * window, const gfx::Rect & old_bounds, const gfx::Rect & new_bounds) Line 623 C++
chrome.dll!aura::Window::OnWindowBoundsChanged(const gfx::Rect & old_bounds) Line 1350 C++
chrome.dll!base::internal::RunnableAdapter<void (__thiscall aura::Window::*)(gfx::Rect const &)>::Run(aura::Window * object, const gfx::Rect & a1) Line 190 C++
chrome.dll!base::internal::InvokeHelper<0,void,base::internal::RunnableAdapter<void (__thiscall aura::Window::*)(gfx::Rect const &)>,void __cdecl(aura::Window *,gfx::Rect const &)>::MakeItSo(base::internal::RunnableAdapter<void (__thiscall aura::Window::*)(gfx::Rect const &)> runnable, aura::Window * a1, const gfx::Rect & a2) Line 899 C++
chrome.dll!base::internal::Invoker<2,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall aura::Window::*)(gfx::Rect const &)>,void __cdecl(aura::Window *,gfx::Rect const &),void __cdecl(base::internal::UnretainedWrapper
chrome.dll!base::Callback<void __cdecl(void)>::Run() Line 401 C++
chrome.dll!ui::Layer::SetBoundsFromAnimation(const gfx::Rect & bounds) Line 833 C++
chrome.dll!ui::LayerAnimator::SetBounds(const gfx::Rect & value) Line 102 C++
chrome.dll!ui::Layer::SetBounds(const gfx::Rect & bounds) Line 245 C++
chrome.dll!aura::Window::SetBoundsInternal(const gfx::Rect & new_bounds) Line 915 C++
chrome.dll!aura::Window::SetBounds(const gfx::Rect & new_bounds) Line 449 C++
chrome.dll!views::DesktopNativeWidgetAura::OnHostResized(const aura::WindowTreeHost * host) Line 1174 C++
chrome.dll!aura::WindowTreeHost::OnHostResized(const gfx::Size & new_size) Line 244 C++
chrome.dll!views::DesktopWindowTreeHostWin::HandleClientSizeChanged(const gfx::Size & new_size) Line 815 C++
chrome.dll!views::HWNDMessageHandler::ClientAreaSizeChanged() Line 1083 C++
chrome.dll!views::HWNDMessageHandler::OnWindowPosChanged(tagWINDOWPOS * window_pos) Line 2307 C++
chrome.dll!views::HWNDMessageHandler::_ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam, long & lResult, unsigned long dwMsgMapID) Line 403 C++
chrome.dll!views::HWNDMessageHandler::OnWndProc(unsigned int message, unsigned int w_param, long l_param) Line 924 C++
Comment 19. originally posted by magreenblatt on 2014-10-28T15:56:07.000Z:
@ comment 18.: The WM_WINDOWPOSCHANGED message currently works as expected in CEF. To fix this issue it will be necessary to also forward the WM_MOVE message to DesktopWindowTreeHostWin.
Original comment by Anonymous.
Comment 20. originally posted by jcmayhew on 2014-10-28T16:14:33.000Z:
Just a heads up that I think this issue affects all platforms.
Comment 21. originally posted by magreenblatt on 2014-10-28T16:50:14.000Z:
issue #1360 has been merged into this issue.
Comment 22. originally posted by magreenblatt on 2014-10-28T16:50:31.000Z:
issue #590 has been merged into this issue.
Comment 23. originally posted by magreenblatt on 2014-10-28T17:28:36.000Z:
To dismiss select popups on window move/resize Aura uses RenderWidgetHostViewAura::EventFilterForPopupExit which is triggered when the non-client area of the window is clicked. For CEF the popup is already dismissed on window resize but we need to explicitly dismiss it on window move.
Comment 24. originally posted by magreenblatt on 2014-10-28T17:40:44.000Z:
@ comment 23.: Dismissal of the popup in Chrome (revision d075289 (bb)) on Windows by clicking in the non-client area:
chrome.dll!content::RenderWidgetHostImpl::Shutdown() Line 426 C++
chrome.dll!content::RenderWidgetHostViewAura::ApplyEventFilterForPopupExit(ui::LocatedEvent * event) Line 391 C++
chrome.dll!content::RenderWidgetHostViewAura::EventFilterForPopupExit::OnMouseEvent(ui::MouseEvent * event) Line 362 C++
chrome.dll!ui::EventHandler::OnEvent(ui::Event * event) Line 29 C++
chrome_child.dll!blink::PopupContainer::hide() Line 354 C++
chrome_child.dll!blink::WebPopupMenuImpl::close() Line 171 C++
chrome_child.dll!content::RenderWidget::Close() Line 1449 C++
Dismissal of the popup by resizing the browser in CEF, renderer process:
libcef.dll!blink::WebViewImpl::hideSelectPopup() Line 1547 C++
libcef.dll!blink::WebViewImpl::hidePopups() Line 3749 C++
libcef.dll!content::RenderViewImpl::OnResize(const ViewMsg_Resize_Params & params) Line 3253 C++
Comment 25. originally posted by magreenblatt on 2014-10-29T18:16:58.000Z:
Trunk revision 1901 and 2171 branch revision 1902 add a new CefBrowserHost::NotifyMoveOrResizeStarted() method that, when called from client applications on Windows and Linux, fix positioning of select popups and dismissal on window move/resize. This problem does not reproduce on OS X so there's no need to call the new method on that platform.
Original comment by Anonymous.
Comment 26. originally posted by jcmayhew on 2014-10-29T21:12:44.000Z:
Any chance of having this patched down to the 2062 release branch? We aren't able to go to 2171 due yet due to some issues we have yet to track down.
Comment 27. originally posted by magreenblatt on 2014-10-31T18:52:05.000Z:
@ comment 26.: Can you test and attach a patch for 2062 branch? Thanks.
Original comment by Anonymous.
Comment 28. originally posted by jcmayhew on 2014-10-31T19:02:44.000Z:
Will do.
Original comment by Anonymous.
Comment 29. originally posted by jcmayhew on 2014-11-04T21:09:00.000Z:
I'm manually incorporating the changes for this but am not quite sure what to do with the patch file mod. There appears to be some git commit ids in there that I'm not sure about
line 60: "index 9831992 (bb)..23a00a9 100644 (bb)"
Is there a process I need to follow to make the required changes to this file?
Comment 30. originally posted by magreenblatt on 2014-11-07T18:25:35.000Z:
@ comment 29.: You should change DesktopWindowTreeHostX11::GetBounds manually in your 2062 branch checkout (with the previous patch already applied) and then run `python src/cef/tools/patch_updater.py --resave` to re-save the views_widget_180.patch file including your changes.
Original comment by Anonymous.
Comment 31. originally posted by Hylinn.Taggart on 2014-12-15T18:14:16.000Z:
Is anyone else still seeing this issue if CEF is a child of another window on Windows? In my case, it appears the WM_MOVE and WM_MOVING are never being sent to CEF.
Original comment by Anonymous.
Comment 32. originally posted by jkeyes@connectwise.com on 2014-12-15T18:42:33.000Z:
After migrating to branch 2171, this issue is not resolved for us.
Original comment by Anonymous.
Comment 33. originally posted by jcmayhew on 2014-12-15T18:51:05.000Z:
I just tried 2171 r1949 and the issue is resolved for me on Windows. My app does get the WM_MOVE and WM_MOVING messages in its message proc.
Comment 34. originally posted by magreenblatt on 2014-12-15T18:54:19.000Z:
@ comment 31.,32: You need to implement WM_MOVE/WM_MOVING in your top-level window and call CefBrowserHost::NotifyMoveOrResizeStarted(). See the example in cefclient.
Original comment by Anonymous.
Comment 35. originally posted by Hylinn.Taggart on 2014-12-15T23:03:33.000Z:
@ comment 34.: Gotcha. My issue arises because, in my case, CEF is wrapped in an ActiveX control which is in turn wrapped by a custom WPF control. I don't have access to change the handling of WM_MOVE/WM_MOVING on those components so I can't tell them to call CefBrowserHost::NotifyMoveOrResizeStarted().
Original comment by Anonymous.
Comment 36. originally posted by jcmayhew on 2014-12-15T23:18:46.000Z:
I would think whoever is controlling CEF, sounds like your activeX control, needs to call NotifyMoveOrResize(started). Your activeX control must get some notification or callback when the control is resized. That would be the place to call this method.
Comment 37. originally posted by magreenblatt on 2015-03-09T21:55:21.000Z:
issue #1537 has been merged into this issue.
Original comment by Dmitry Azaraev (Bitbucket: Mystic Artifact).
In addition to this issue: Starting from 3.2062 (tested over cefclient 3.2062.1930) we have next invalid behavior: clicking on select box (combobox) when cef window in background did not opens popup window. It is did not completely eat click, it is focus select box (you can even see yellow border around for a short time), probably it is even try to show popup, but it is did not appears on screen (may be immediately closed for some reason).
Regardless to original problem is that it is still incorrect, and can be reproduced in cefclient. I.e. at least cefclient did not implement any kind of 'reference' implementation.
Dropdowns of course can be dismissed with window move or window resizing, but any menu or dropdown-like popup should be dismissed when we perform any action unrelated to dropdown. This means that popup window should be dismissed on many events, like mouse down, which we usually never handle directly.
Originally in Win32 classics this problem easily solved with capturing mouse input, and implementing window dismissing logic inside popup window itself together with handling any required event processing. Chromium instead captures mouse input for whole (root) window for some reason, and make decision on higher level. This is works fine and correctly inside chromium, but not handy for any embedded case, 'cause require implement additional logic every time. This also will require window hacking (subclassing), in order, when we did not own parent window (easily happens on window reparenting). (Actually in my case even subclassing is not an option, for reability reasons).
NotifyMoveOrResizeStarted mentally are not connected with popup dismission, so we did not known, how safe we can call it, for example, from WM_MOUSEDOWN event handler.
Original comment by Said Elkhazendar (Bitbucket: said_elkhazendar).
Hi Marshall
This issue still exist in Branch 2454 (2454.1326). Can you please add fix in https://code.google.com/p/chromiumembedded/issues/detail?id=1208#c25 to this branch?
Thanks
@said_elkhazendar : 2454 branch already includes any fixes from this issue. See comment # 34 for correct usage. If you are experiencing a problem please ask on the CEF Forum.
Original comment by Said Elkhazendar (Bitbucket: said_elkhazendar).
For Branch 2062
Need to implement https://code.google.com/p/chromiumembedded/source/detail?r=1902 and call CefBrowserHost::NotifyMoveOrResizeStarted() on window event handler ON_WM_WINDOWPOSCHANGED(). Ensure you call base method __super::OnWindowPosChanged(lpwndpos), otherwise your browser object will not draw properly.
You may also need to pass the message to the view.
Original comment by Said Elkhazendar (Bitbucket: said_elkhazendar).
Hi Marshall Greenblatt
In Windows 10, libcef.dll crashes at the main message pump if we handle this case as suggested on WM_WINDOWPOSCHANGED when called as the user is closing the window. Seems the call still gets called while the browser is in process of being destroyed. This happens only on Windows 10 x86 and x64 versions of libcef crash. Tried with branch 2526 and 2623. The crash at the pump seems irrelevant but after some trial and error we concluded this is the cause of the issue.
Note: This crash is easily replicated when using Google Docs, with a large list of google docs, or when using extensions such as opening PDF and then closing the window.
void CSomeView::OnWindowPosChanged(WINDOWPOS* lpwndpos)
{
__super::OnWindowPosChanged(lpwndpos);
if (m_pHandler->m_Browser)
{
if (IsWindow(this->m_hWnd) && IsWindow(m_pHandler->m_BrowserHwnd))
m_pHandler->m_Browser->GetHost()->NotifyMoveOrResizeStarted(); //Crashes for pop-out and MDI windows.
}
}
Crash stack: user32.dll!_NtUserGetMessage@16 () Unknown
user32.dll!GetMessageA() Unknown
mfc120.dll!AfxInternalPumpMessage() Line 153 C++
BOOL AFXAPI AfxInternalPumpMessage() { _AFX_THREAD_STATE *pState = AfxGetThreadState();
if (!::GetMessage(&(pState->m_msgCur), NULL, NULL, NULL)) //Crash here with this data pState->m_msgCur {msg=0x00000113 wp=0x0000754b lp=0x72e68520}
{
TRACE(traceAppMsg, 1, "CWinThread::PumpMessage - Received WM_QUIT.\n");
pState->m_nDisablePumpCount++; // application must die
// Note: prevents calling message loop things in 'ExitInstance'
// will never be decremented
return FALSE;
}
Original comment by Saurabh Bhardwaj (Bitbucket: Saurabh Bhardwaj).
Hello guys, this seems to be fix in the CPP files; how can I fix this using the .net source project files? Please suggest. Thanks.
Original report by Anonymous.
Original issue 1208 created by ryan.goat on 2014-02-18T12:46:49.000Z:
* What steps will reproduce the problem?
What is the expected output?
* The combobox dropdown menu should appear under the combobox.
What do you see instead? The combobox menu appears underneath where the combobox would be located if the CEF browser window had not been moved in step 2.
* What version of the product are you using?
CEF 3.1750.1619_windows32
Compiled with visual studio 2012.
CEF_ENABLE_SANDBOX=0.
* In what operating system?
Windows 7 professional SP1