Add Url to JavascriptBindingEventArgs - #5021

✅ Build CefSharp 131.3.10-CI5135 completed (commit 3de1bade0e by @amaitland)

✅ Build CefSharp 131.3.10-CI5137 completed (commit 89b7d8ee83 by @amaitland)

I had originally though about exposing the JS repository and method runner queue for users to customise, reverted this change as I'm not sure that it's wise.

✅ Build CefSharp 131.3.10-CI5141 completed (commit 80c0d4edbe by @amaitland)

@amaitland I’ve done a deep dive into the origin restriction security issue, and unfortunately, this approach doesn’t fully resolve the problem.

Here’s the core issue: in the JavascriptObjectRepository_ResolveObject(object sender, CefSharp.Event.JavascriptBindingEventArgs e) method, it’s not possible to prevent object registration in JavaScript when CefSharp.BindObjectAsync() is called.

For example:

1. A browser instance has a main frame and several iFrames.
2. The main frame, with an allowed origin, successfully calls CefSharp.BindObjectAsync(), and objects are registered.
3. None of the iFrames can access these objects, which is correct.
4. However, if an iFrame with a disallowed origin calls CefSharp.BindObjectAsync(), the JavascriptObjectRepository_ResolveObject method is triggered. Since the objects are already registered in the JavascriptObjectRepository (i.e., IsBound(objectName) returns true), simply returning from the method gives the iFrame access to these objects. Currently, the only option to prevent this is to call javascriptObjectRepository.UnRegisterAll(), but this also removes access for the main frame, which is not ideal:

//  
// Summary:  
//     Unregister all the currently bound objects from the repository.  
//     If you unregister an object that is currently bound in JavaScript,  
//     method/property calls will fail.  
void UnRegisterAll();  

This limitation makes it difficult to manage object access based on origin securely.

I’ve done a deep dive into the origin restriction security issue, and unfortunately, this approach doesn’t fully resolve the problem.

Nor is it expected to. This is just a piece of the puzzle.

Additional code changes would be required as per my comment at #5001 (comment)