Dropdown values not following the mouse

[jimbourekas]

I wrote it as a comment at #162

Is it possible that there still exists a case where the drop down appears away of the expected place? I get such a behaviour even with the WPF demo of v1.25.5. To reproduce, go to http://signup.live.com and play with the Day and Year dropdowns. After a while you'll see that the mouse cursor is not in sync with the dropdown value.

If it helps at all, I see that when clicking at a dropdown box, momentarily I see the values of the previously clicked dropdown. Then for a moment I see blank and then the new values.

On windows7 x64

Can someone please confirm? Here's a video displaying part of the problem: http://codepoets.gr/tmp/cefsharp/11-27-2013.wmv

Cheers.

Jim

[perlun]

Hi,

I think this is the same as #213 - what do you think? Could you test with the latest CefSharp1 code (by cloning the code here on Github, or just downloading the zipball) and see if the problem can still be reproduced?

I haven't had much time for CefSharp (neither 1 or 3) lately, but we should try to get a v1.25.6 out the door reasonably soon, just to catch up with the latest minor fixes that's been coming in.

[jimbourekas]

Per hi,

I had applied the changes from #213 without any luck.

I can still reproduce the problem with the latest from CefSharp1 code from github:

New video here: http://codepoets.gr/tmp/cefsharp/11-28-2013.wmv

[jimbourekas]

Ok, more updates:

The scenario that fails is:

1. open https://signup.live.com
2. make the application window (i.e. wpf-example.exe) short (for example 300px)
3. scroll down the webpage so that the dropdown fields are at the bottom of the window
4. move the whole application window at the bottom of the desktop
5. try to expand the dropdowns

if I explained clearly then your cursor is not in-sync with the dropdown.

I guess there's something wrong here? Regarding the location of the popup with the dropdown values...

    void WebView::SetPopupSizeAndPosition(const void* rect)
    {
        auto cefRect = (const CefRect*) rect;
        _popupX = cefRect->x;
        _popupY = cefRect->y;
        _popupWidth = cefRect->width;
        _popupHeight = cefRect->height;

        if(!Dispatcher->HasShutdownStarted) {
            Dispatcher->BeginInvoke(DispatcherPriority::Render, _resizePopupDelegate);
        }
    }

[perlun]

Sorry for the lack of updates on this one; I've been incredibly overworked lately at work. Hence, CefSharp hasn't received the TLC it deserves. This is one of the issues that we should focus on, but I'm unfortunately not sure that we will get an answer until some more week. Hang in there; in the best of worlds, I'll try to get it resolved before the Christmas break.

If anyone wants to fix it and send in a PR - by all means, feel free to do so...

[jimbourekas]

I'm holding my breath on this one, we're going live on a couple of days and I have only put together a small workaround (using javascript to give a "size" attribute to the dropdowns so that they actually occupy a certain place on the page instead of poping up).

Thanks for the update

jim

[perlun]

Hi,

Looking into this right now, and I have managed to reproduce it. I think the reason why it goes wrong is that the popup is actually displayed "outside" of the main window, so that's likely why the cursor offset is a bit messed up.

If I compare CefSharp1 with a normal Chrome (latest version), I can see that they differ in how they place the popups. In Chrome, the popups are often placed above the dropdown, whereas in CefSharp1, they are most often placed below the dropdown. This could possibly be the cause.

Unfortunately, we haven't got support for dropdowns in CefSharp3 (#200), which uses a more recent Chromium version, so I think I will try to fix that now to see if the problem exists there also.

[jimbourekas]

Ok, let me know if you want me to test anything.

cheers

jim

12 Δεκ 2013, 21:37, ο/η Per Lundberg notifications@github.com έγραψε:

Hi,

Looking into this right now, and I have managed to reproduce it. I think the reason why it goes wrong is that the popup is actually displayed "outside" of the main window, so that's likely why the cursor offset is a bit messed up.

If I compare CefSharp1 with a normal Chrome (latest version), I can see that they differ in how they place the popups. In Chrome, the popups are often placed above the dropdown, whereas in CefSharp1, they are most often placed below the dropdown. This could possibly be the cause.

Unfortunately, we haven't got support for dropdowns in CefSharp3 (#200), which uses a more recent Chromium version, so I think I will try to fix that now to see if the problem exists there also.

—
Reply to this email directly or view it on GitHub.

[perlun]

Hi @jimbourekas,

I actually managed to find a fix, eventually... after spending a couple of hours yesterday working on the CefSharp3 popup support and then digging into the CEF code today. It turned it it wasn't so hard after all; we have to implement a few methods to make CEF be more aware of the size of our viewport.

Please test the latest CefSharp1 source (from Github, it's not released yet) to make sure it works for you. We can then release an update of CefSharp1 during next week.

And finally, please let me know where I can send the bill... 😉

[jimbourekas]

Per, it seems to work! I can see the popup expanding above the dropdown so I guess this is identical to how Chrome handles it. I will report back if something strange happens.

Regarding the bill now.... I thought we were just scratching itches here!

I'm kidding. Is CefSharp even accepting donations?

Regards,

jim

[perlun]

Glad to hear it works! Yes, it seems identical to how Chrome expands the dropdowns, which is good. I will try to make a 1.25.6 release during next week or something.

Hehe. 😉 Not formally, but I actually got the privilege to work on this on company time (I have a kind employer...). So, if you want to, email me (perlun at gmail) and we can discuss that a bit further.

(actually, I think it would be good for the project if we could start taking in "donations" or sponsored work in some way. It makes things more serious and I don't think its totally unreasonable that people would pay for features which are critical to them. In this case, I didn't mention this in advance to you, but we could definitely start doing something like "pay $100 and get it fixed now or don't pay and get it fixed "sometime"". I don't think that would be so bad, but then again there would perhaps be some people that would be offended. I don't know.

[jimbourekas]

Donations are always a nice thing to have but "sometime-fixes" vs "now-fixes" are tricky and can completely cause people to feel offended. If you want to start charging for a product, you normally would have to make sure that it has reached a level of quality. Misplaced dropdowns and things like this make it a non-100% complete product. I'm not trying to be a jerk now and I honestly appreciate the hours you've put on this. Having said that, I would start accepting donations anyway, for anyone who feels like they want to support the team. I wouldn't just yet separate the fix priorities ("sometime" vs "now" fixes) unless CefSharp gets to a fully operational state. Then, I could charge a fee for new feature requests and maybe priority fixes (this one doesn't feel right though)...