I just upgrade EO.WebBrowser from 18.3.46 to 19.0.56 and left click no longer registers when clicking on a WebControl

Interestingly, right click works, as does the mouse over cursor changes for moving over text boxes and buttons, but left clicks do not seem to be detected.

I added an event handle to the WebView for clicks but it is never called.

Any insight here would be helpful.

Edit: Modified Post title to clarify problem

Perhaps related; (winforms)

If you create a html page with a single text input element, and click in it - you can type in it as normal.
Next, if you try to navigate within your typed text left or right with the arrow keys, focus jumps out of the element and around the page

> We did confirm the arrow key issue. This will be fixed in our next build.

cheers for that, and sorry for polluting the thread if it's a different issue.

The main change in this build is that it reroutes all input to your application first and it mainly impacts keyboard events. For example, if you have a main menu item "&File" and user press Alt + F inside the WebView, then the browser engine will route this event to your host application and subsequently this event will be "eaten" by the main menu and will not be processed by the browser engine. This is how other "normal" Windows Forms control works but it didn't work this way for older version of EO.WebBrowser because the browser engine in fact runs in a different process. In this release we have added a lot of code under the hood to make it as transparent as possible to the end user so it works the same way as normal in process controls. The same change also caused Bob's problem because certain keys such as arrow keys should not be passed to the host application and that issue will be corrected in our next build.

Since the change mainly impact keyboard events, we do not know why mouse click stopped working for you. It does work fine in our test environment as well as in your test app as you noticed. So we won't be able to tell you much without a reproducing app.

You will need to create a test app in order for us to investigate this further. We can't shoot in the dark and expect it to hit the target.

Don't argue with us. You are not shooting in the dark. You do see the problem. We do not see the problem. The fact that it only appears in your application means it must have something to do with your application. And in order for us to look further, you will need to isolate that part and send it to us. You keep asking us for clues only because you don't want spend time to do that part. You need to do your part. We are very clear and firm on this so the sooner you can get your test app to us the sooner this issue will be resolved for you.

There have been literally millions line of code changes between these two versions. These are two separate different versions of Chromium browser engine that are a year apart. Hundreds of change lists have been checked into Chromium project on daily basis. The whole project contains over 25 million lines of code. For a project of this scale, we don't work on the "clue" approach you prefer. It is not possible for us to work on "let's try this", "maybe it's this" kind of troubleshooting because there are so many things that can go wrong. If it is something obviously, such as Bob's problem, we will be able to tell right away and won't ask him for a test project. This is not the case for your issue. Not only "maybe it's this" approach will waste more of both your time and our time, we might stumble on something that accidentally silent the problem without finding the root of the problem, just like silencing an alarm without actually find out the root of the alarm. That would be bad news not only for us, but for you as well because the same issue can resurface at a later time in a different form.

We've been in this business for a long time and you are not the first person trying to get around this --- you really need to do what we tell you to do. And we say this very publicly in our support forum. This is not about being aggressive, this is about being practical and methodological. For your issue to be resolved, it needs to be reproduced, fixed, tested and verified. Very often the first step and the last part needs a repro from the customer because the first step helps us identify the problem and the last step (verify) ensures whatever we come up indeed resolve the exact issue the customer encountered.

We will work with you to our best ability only if you work with us and as a business, we can not allow a single customer to dedicate how we work. So if you can not accept this, your issue will not be resolved. It's as simple as that. If that is not acceptable to you, then we can only kindly ask you to take your business elsewhere. We will be very happy to issue you a full refund in that case. Please confirm.

Hope this makes our position clear enough to you. Please consider this as our final decision on this matter and keep in mind we will not allow unnecessary argument to drag on in our support forum. You may send us a test project by following the link we provided, or request a full refund by directly replying this post or contact us separately through the contact us page and mention this thread.

This is excellent information and it makes perfect sense. One of the major change of the new version is that it reroutes the input events through your application first before processing it further in the browser engine. This was intended to make the WebView works more "alike" other standard controls and honor WPF ways of event processing (and Windows Form's way in the Windows Form version). For example, if a parent control "eats" the event in the bubbling phase, the event will not travel back to the browser engine.

In order to properly resolve such issues, we will need to clearly identify each cases first. They falls into these categories:

1. The WebControl/WebView is rerouting the events properly and somewhere along the event chain in your application the event was eaten. For example, you could have shortcut Ctrl + P on your Window object that will trigger printing. This is the way it supposes to work and if you wish Ctrl + P to reach back the WebView, you will have to modify your application not to handle this shortcut;

2. The WebControl/WebView is rerouting the events property but it is not practical/possible to change the code in the application to avoid the event being consumed. For example, you may have the WebControl placed inside a ScrollViewer but still want user to be able to scroll the WebView with mouse and it is not easy to modify the ScrollViewer's behavior since it's not your code. This would require us to provide a way for you to selectively stop re-routing certain events. We will need to change our code in order to support this. We are currently getting similar feedbacks from other users and we are looking into this. The challenge for us is not to support it, but rather to support it with a simple, easy to use and yet flexible and powerful enough interface that can cover as many scenario as possible, while still preserve the native WPF/Windows Forms event handling semantic/flow as much as possible. If that's not possible, the worst case is to add a switch to turn event routing off and keep everything happened in the WebView to the WebView itself. If you can send test cases to us it will help us to refine our implementation;

3. The WebControl/WebView is not routing the events properties. An example of this would be typing in the WebView but the characters show up in another control. In your case if your ListBox is not the parent control of the WebControl, then this can be a case of not routing properly as well since event should not be routed through siblings. In this case please send us a test project and we will investigate further.

Hi,

This is an interesting observation.

WebView is not a WPF control. So it does NOT follow WPF rules. In fact WebView is purposely designed to be platform neutral, so that the same class works the same way either be with WPF, or with Windows Forms (which routes events differently than WPF), or just being used alone without either platform. We try to maintain some consistency between different platforms, specifically regardless platform, the same event is always fired on WebControl before being fired on the corresponding WebView. It appears that this would be problematic. We are reviewing this area and please feel free to post again if you have any other inputs.

Thanks!

We were about to tell you this is exactly why we asked you to create a test app. :) The goal is not just the test app itself, the goal is to narrow down on exactly what caused it. In your case as soon as you tell us the event was consumed by ScrollViewer it immediately makes sense that this could cause your issue. That was the key piece of information that wasn't obvious at the beginning.

In hind sight we would definitely say we should have thought about this at first place because the VERY PURPOSE of rerouting events through your application is to allow your application to "eat" it --- that was the design goal of this whole thing. However when the issue just surfaced freshly after so much code changes, it's difficult for us to make the connection right away. As we hear more from our customers, such cases would transform from "difficult" cases to "obvious" cases. A key part of this is your effort to isolate it and it is much appreciated.

We are doing an in depth review on this area and I am sure both your feedback and your test app will be very helpful in this process. It might take some time for us to come up with a clean solution or relatively elegant compromise. We will reply here again if we have any update or need anything additional from you.