I’m working on a console-based browser application using C# with Awesomium.Core library. I need help with properly managing the ShowCreatedWebView event.
When new browser windows are created, I want to capture them and integrate them into my main browser view. The official docs show an example using WinForm controls:
private void HandleNewViewCreation(object source, ShowCreatedWebViewEventArgs args)
{
var formControl = source as WebControl;
if (formControl?.IsLive != true) return;
var popup = new PopupWindow();
// additional setup code
}
Since I’m building a headless console app, I can’t use WinForm controls. The documentation mentions these steps for Awesomium.Core:
- Wrap the NewViewInstance using WebView constructor
- Set ParentWindow for windowed views or configure ISurface for offscreen views
- Adjust WebView dimensions
I tried this approach:
browserView = new WebView(args.NewViewInstance);
browserView.Resize(800, 600);
The result is a blank page that doesn’t seem to load the expected content. I’m expecting a download event to trigger after the view loads, but it never happens.
Am I missing something in the view creation process? How should I properly handle new WebView instances in a console environment?
I had the same issue building a headless scraper with Awesomium. What fixed my blank pages was calling FinishCreation() on the WebView after setting up the surface but before resizing. Do it in this order: wrap NewViewInstance, configure surface, call FinishCreation(), then resize. Without FinishCreation(), the WebView won’t initialize properly even though it looks like it created fine. Also, use LoadingFrameComplete instead of DocumentReady - popup windows have weird loading cycles. Your download events might be firing on a different chain than you think.
The issue with the blank page arises from missing event handlers and surface setup. In console applications using WebViews, it’s crucial to configure the full rendering pipeline. Once you wrap your NewViewInstance, ensure you set up the surface for offscreen rendering, as even headless WebViews require a valid surface. It’s essential to verify that IsLive returns true before proceeding. Importantly, connect the DocumentReady event handler to your new WebView; without it, you won’t receive notifications when content loads, which is likely why your download events aren’t triggered. I encountered this issue when transitioning from WinForms to a console setup with Awesomium, and resolving it involved hooking up all lifecycle events prior to processing the view.
WebView instances in console apps are a pain. I’ve watched teams bang their heads against this same wall when building headless automation.
It’s not just the missing surface config - you’re using a library that wasn’t built for modern automation. Even if you nail the surface setup and wire all the events correctly, you’ll get memory leaks, weird behavior, and debugging hell.
We learned this the hard way after spending weeks making Awesomium work in production. Constantly fixing view lifecycle bugs and event handling issues.
Better to use a proper automation platform that handles this mess for you. Skip the low-level WebView wrestling and focus on your actual business logic. Modern tools manage browser instances, events, and content loading automatically.
Latenode kills these headaches completely. You define what happens when new windows open, it handles the browser management. No blank pages, no missing events, no manual surface config.
Check it out: https://latenode.com
you’re missing the surface configuration step. after wrapping NewViewInstance, call CreateSurface() or assign an ISurface implementation before resizing. without surface setup, the webview can’t render anything - that’s why you’re getting a blank page. also check if the parent webview has focus set correctly since this affects child view behavior in console apps.
Make sure you’re creating the view on the right thread. Awesomium needs WebView operations on the UI thread, which gets messy in console apps. When you wrap NewViewInstance, you’ve got to call WebCore.Update() regularly in your main loop - console apps don’t auto-pump messages like WinForms does. No regular updates means your WebView won’t handle navigation events or trigger downloads. I fixed this by setting up a timer that hits WebCore.Update() every 50ms and keeping all WebView stuff on the same thread where I initialized WebCore.