Dropdowns fail after minimize, maximize

[RadicalLinux]

Okay this issue occurs between tag 33.0.2 and then new 37.0.0.pre01 with WinForms 33.0.2 works fine

HTML dropdowns on hidden tabs stop working properly after minimize, maximize. This does not seem to happen with Windows Tab Control like in example, but does happen with Dockpanel Suite.
The dropdown is still there, but is no longer in the proper position (They may be off screen or outside of the application.)

Now I am unsure of which commit broke the functionality, but I'm wondering if the Focus commits have broken something. I did try using the later versions of CEF (that addressed the issue in #655) to no avail.

[amaitland]

Dockpanel Suite

@RadicalLinux What exactly is Dockpanel Suite? Do you have some code to reproduce the issue?

[RadicalLinux]

https://github.com/dockpanelsuite/dockpanelsuite/ <-- Using the 3.0pre version.

I can write up some code quickly. First I'm testing your 2171 branch to see if the issue is still occuring in that branch.

Okay does happing in 2171 also. Let me put together a quick project.

[RadicalLinux]

Okay, here is a sample sorry for the size (I've enclosed the source and also the Debug/x86/ folder compiled with the version of cefsharp. You might want to run that first.

Open up 3 or 4 new windows. They just show a drop down. Then minimize the application. Then maximize. Now go to one of the tabs that was not visible before the minimize. Try the dropdown. This doesn't even have to be on maximize/minimize. It can occur on any window resize. The visible tab is always fine, but the hidden ones no longer work properly.

http://owncloud.facebot.org/public.php?service=files&t=954b1ee813a62c734893a6cae85db171

[amaitland]

Can you push the code to github please? Binary dump may demonstrate the problem, then need to be able to debug it.

[RadicalLinux]

I included the full code/project in that file. Is there something more I need?

[amaitland]

I'd prefer the source in a more open source friendly place like github, or a gist, or something similar. Few reasons for this

• Security: I'm overly cautious on that front (and I'd encourage others to be so as well)
• Openness: lowers the barrier to entry, meaning that more people may look at your issue.

[RadicalLinux]

I've never published to GitHub. So I'm trying to do it now.

[amaitland]

It's easy enough :smile:

[RadicalLinux]

Actually it's not, I've created a bunch of repositories and can't get anything in them. I'm on my 4th client, and I've even tried command line. When I can get some files up, I can't get a folder. This is insane! SVN was never this complicated.

[RadicalLinux]

Okay, teach me for using windows for anything other than initial development. Switch to linux and works!

https://github.com/RadicalLinux/CefDock

The DockPanel dll is in the debug folder.

[skillbert]

Id like to add to this issue that dropdowns on a topmost window appear behind the window itself.

[amaitland]

@skillbert Are you using the Dockpanel Suite as well? If your problem to do with dropdowns, though with a different scenario then open a new issue please.

[amaitland]

@RadicalLinux Can you provide a step by step guide to reproduce your issue so when someone does look at your problem they have sufficient information.

[skillbert]

I just did some tests and it seems unrelated to the library. The dropdowns appear relative to the last position that the browser was loaded/maximized/minimized. This happens with the latest version using winforms.

[skillbert]

Opened a new issue for the topmost problem as that remains unrelated as you said. #657

[RadicalLinux]

@amaitland Using the Test Application listed previously:

1. Open up 3 or 4 new windows (By Clicking New Window). The page just shows a drop down.
2. Minimize the application.
3. Maximize the application.
4. Go to one of the tabs that was not visible before the minimize.
5. Try the dropdown - You'll notice it doesn't appear to drop down, though you can arrow down to next items.
6. You can also resize the application window to get the same effect.
7. The visible tab is always fine, but the hidden ones no longer work properly.

[amaitland]

I believe this is the commit your looking for https://github.com/cefsharp/CefSharp/commit/b72f3b757cfdf593615a5a398228f06e6963ccb9#diff-f81cf6df3af1093f674f5729017b960e

[RadicalLinux]

@amaitland Is that the commit you think broke it or that fixes it? I guess I'm a little confused, but it does appear that this commit (whether fixes or not) is the issue.

Okay I see that it was the fix for another issue, and ended up breaking it here.

[RadicalLinux]

Okay I did 2 things, one I re-added the OnPaint stuff while leave the stuff from the new commit and that did not resolve the issue. I then reverted to the files before the commit and that resolves the issue. It appears that Resize is not getting the proper sizes and/or not updating when it needs to be updated.

[amaitland]

It appears that Resize is not getting the proper sizes and/or not updating when it needs to be updated.

As it works correctly with the built in TabControl I have to wonder if it's the dockpanelsuite which isn't providing the relevant notification?

[RadicalLinux]

That is entirely possible. I have narrowed down the 1 function that seems to be the issue.

protected override void OnSizeChanged(EventArgs e)
        {
            base.OnSizeChanged(e);
            if (managedCefBrowserAdapter != null)
            {
                ResizeBrowser();
            }
        }

It's not been an issue till these latest changes were made though. It always handle them perfectly. Except when there was issue in the upstream.

[RadicalLinux]

@amaitland Okay, I can tell you that the DockPanel Suite works the way it's supposed to at least according to 2 different dockpanel control creators. The middle forms are considered documents, not tool windows like the side docks. The hidden documents do not update when minimized, only when activated. This is different from the Tab Control. So this behavior is not going to change. BTW DockPanel Suite allows you to create the same interface that Visual Studio uses.

After adding some debugging code to the commit, I was able to determine, that on initial layout, ResizeBrowser is called on ALL open document windows as the control is initialized, which is what should happen based on the commit code. When the application is minimized, the visible document does resize to 0x0, while the hidden documents do not. When maximized, once again, the visible document once again calls ResizeBrowser, while the hidden ones do not. Even making them visible does not resize.

[amaitland]

Sounds like it might have to be handled at a slightly lower level then.

Probably worth looking at the cefclient example application https://bitbucket.org/chromiumembedded/branches-2062-cef3/src/a073e92426b3967f1fc2f1d3fd7711d809eeb03a/tests/cefclient/cefclient_win.cpp?at=master#cl-599

[amaitland]

Note to future self http://stackoverflow.com/a/1052921

[RadicalLinux]

@amaitland Okay I did a lot more debug checking on this. It's apparent that Resize event is getting called on the cef control even if they are on hidden tabs. It is getting called on minimize/maximize/etc. It is also getting the proper Width/Height values for the control. I added the event and works properly.
I'm wondering if the control is not updating on the hidden tabs.

[amaitland]

When the application is minimized, the visible document does resize to 0x0, while the hidden documents do not. When maximized, once again, the visible document once again calls ResizeBrowser, while the hidden ones do not

This sounds a little inconsistent to me, perhaps worth asking the DockPanel Suite people for an opinion?

[RadicalLinux]

@amaitland I was wrong, it seems the windows do call that information, but don't repaint/update. Here is the temporary work around I found, which isn't the greatest:

 private void frmBrowser_Enter(object sender, EventArgs e)
        {
            var width = browser.browser.Size.Width;
            var height = browser.browser.Size.Height;
            browser.browser.Size = new Size(0,0);
            browser.browser.Size = new Size(width,height);
        }

This is the tab, that when they click it the Enter event is fired and then I basically just resize the browser, definitely not elegant, but works for now.

Now it works, but then I found the next issue, and this one I think is the other one that is listed here. It's the drop downs don't move properly. The one affects the Winforms Example too.

Here's how to replicate:

1. Run the Winforms Example, and size the window to be smaller than maximized.
2. Open url http://www.facebot.org/test.html (It's just the page with 1 select/option dropdown
3. Open multiple tabs with this url
4. Now move the example to the right/left/top/bottom on the screen.
5. Now try the dropdowns on the tabs. You will see they are no longer aligned to the original but to the left of the original.

http://prntscr.com/5c022p

[jornh]

https://code.google.com/p/chromiumembedded/issues/detail?id=1208 seems related to the dropdown issue. It's implemented in a newer version of the CEF 2171 branch than the one which CefSharps 2171 branch currently is on.

[amaitland]

Looks like there's talk of it being backported to 2062

[amaitland]

Strange that build 1902 appears to be the most recent for the 2171 branch on windows, and yet there are newer builds for other OS's

[amaitland]

Ignore my last comment, it's irreverent for this issue. The 2171 branch is using 3.2171.1902, so it should be possible to fix this.

[RadicalLinux]

Okay I've tested with the latest 2062, since 37.0.0.pre01 uses it, and the issue has not been fixed. I'll try with 2171 branch.

[RadicalLinux]

Okay my little fix did not work. I've now tried 2 different dockpanel libs and cefsharp does not function properly with either of them. Resizing seems to be the issue. Both DockPanel controls do not do handle paint events when they are hidden.
One of the things I did notice that may help with tracking this all down is that the dropdown window does not stay constrained within the control. If the control is smaller than the text in the dropdown, the drop down will overlap onto the parent control or even outside of the application, if the application window is to small. I believe this is the root of the issue and I'm not sure whether this is an upstream issue or not.

[amaitland]

Moving the window and the drop downs not moving is an upstream issue, there's a chance it will be backported into 2062, it can be fixed in 2171.

[RadicalLinux]

2171.1902 is the version of CEF I'm using which is the one that it's supposed to be fixed in. It's not. I've used other browser controls on the dock panels and had no issues with drop downs (Awesomium, MozNet, Standard Browser). I know the paint event doesn't get called if the control is on a non-active document tab. When the tab becomes active, it doesn't get called either. Now the control does throw the resize event on all the tabs, even if hidden. Is the control not be invalidated after a resize?

[amaitland]

it can be fixed in 2171

I think you may have misunderstood, the fix has been implemented in upstream 2171.1902, it still requires a change to CefSharp

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.

Did you read the issue posted above?

[RadicalLinux]

Yes I read that issue, didn't realize it needed to be implemented in Cefsharp. I fairly new to wrapper development. I don't fully understand it completely.

[amaitland]

cefclient example code https://bitbucket.org/chromiumembedded/branches-2171-cef3/src/23a7f9fe1fc2ef87fc30a19c1ea3484459ab3822/tests/cefclient/cefclient_win.cpp?at=master#cl-653

[RadicalLinux]

I"m wondering if this might be something to implement too: virtual void NotifyScreenInfoChanged() and virtual bool IsWindowRenderingDisabled()

https://bitbucket.org/chromiumembedded/branches-2062-cef3/src/a073e92426b3967f1fc2f1d3fd7711d809eeb03a/include/cef_browser.h?at=master#cl-462

The WasHidden and some of the others only work when window rendering is disabled. I'm not totally sure what they mean by window rendering is disabled. Is this something you have to set? I've managed to implement the WasHidden and Invalidate. But I'm not sure if they actually work since they require window rendering disabled.

[amaitland]

I believe IsWindowRenderingDisabled refers to OffScreen Rendering which is what the WPF control uses. Most of those methods aren't relevant to WinForms.

[RadicalLinux]

Ah, then the implementations may work, just not for Winforms. Is there a reason it's used for WPF, but not Winforms?

[amaitland]

https://code.google.com/p/chromiumembedded/wiki/GeneralUsage#Off-Screen_Rendering

[RadicalLinux]

Well here is some good news. I've implemented the NotifyMoveOrResizeStarted method, and it is resolving some of the issues. Now my visible page is messed up but the hidden pages work if I call the method when the page becomes active.

[RadicalLinux]

Okay, but the commit for Resize is does not work still. I did modify it to be similar to the Cefclient and that seems to resolve the issue.

        void Resize(int width, int height)
        {
            CefWindowHandle hwnd = _renderClientAdapter->TryGetCefHost()->GetWindowHandle();
            if (hwnd) {
                  if (width <= 0 && height <= 0) {
                    // For windowed browsers when the frame window is minimized set the
                    // browser window size to 0x0 to reduce resource usage.
                      SetWindowPos(hwnd, NULL,
                          0, 0, 0, 0, SWP_NOZORDER | SWP_NOMOVE | SWP_NOACTIVATE);
                  } else {
                    // Resize the window and address bar to match the new frame size.
                    RECT rect;
                    GetClientRect(hwnd, &rect);
                    HDWP hdwp = BeginDeferWindowPos(1);
                    hdwp = DeferWindowPos(hdwp, hwnd, NULL,
                        0, 0, width,
                         height, SWP_NOZORDER);
                    EndDeferWindowPos(hdwp);
                  }
              }
        }

Now I'm not sure if that is proper, but that does fix both move and resize issues on all the hidden forms. It does not break the example at all, and now move works perfectly with it too.

Of course this was also with the NotifyMoveOrResizeStarted method implemented too.

[amaitland]

Feel free to create PR and we can discuss your code further :+1:

[RadicalLinux]

@amaitland it took me 3 hours just to push 1 project up LOL. PR? Remember I'm not a git person what so ever. Is there some program/utility you use that makes Git easy?

[RadicalLinux]

BTW, This actually fixed almost all my issues. I need to fix or implement move in Cefsharp and I think I'll be good. BTW I'm using the 2171 branch.

[amaitland]

I used TortoiseSvn for years, so the transition to TortoiseGit ended up being pretty easy. Lots of other clients out there.

https://github.com/cefsharp/CefSharp/wiki/Simple-Guide-to-Forking-and-Creating-a-Pull-Request

[RadicalLinux]

Thanks, I'll take a look at that and also look at doing the PR.

[RadicalLinux]

Yes, I remember Tortoise, I used to use it all the time with a CVS repository. Talk about dating myself. I loved it then and already I have a fork I'm working on.