Posted on
DotNetBrowser 1.13
This version of the library was extended with the features, allowing to intercept all the URL requests for both standard URL schemes (such as http, https, ftp, file), and custom schemes declared in your application. After registering a protocol handler for a scheme, all the URLs with the specified scheme loaded into the Browser will be handled by this handler.
Protocol Handler
Implementing a new custom protocol handler in DotNetBrowser is pretty simple:
public class HttpsHandler : IProtocolHandler
    {
        //This method should provide the response for the specified request
        public IUrlResponse Handle(IUrlRequest request)
        {
            string htmlContent = "Request Url: " + request.Url + "\n";
            return new UrlResponse(Encoding.UTF8.GetBytes(htmlContent));
        }
    }
This custom protocol handler can then be installed for the particular BrowserContext:
browser.Context.ProtocolService.Register("https", new HttpsHandler());
After the handler is installed, any URL having the https scheme will be handled by this custom handler. See an example.
BrowserPreferences.CrashDumpDir property
The BrowserPreferences.CrashDumpDir is a read-write static property which can be used to specify the directory for storing the generated Chromium crash dumps. This property should be specified before creating any Browser or BrowserView instance in your code.
Fixed issues:
- Heavyweight 
WPFBrowserViewnot shown properly when placed inside an Expander control. Before the fix, theBrowserViewappeared to be misplaced after collapsing and restoring the Expander. - Heavyweight 
WPFBrowserViewdisposed improperly for the case when theWindow.Closingevent was canceled for a parent window. - The focus issue when the 
FireMouseEventsEnabledproperty was set to true in the heavyweightWPFBrowserView. Now, the drop-downs on the web page are working properly on a mouse click when this option is enabled. - Calculating the bounds in the heavyweight 
WPFBrowserViewfor the environments with the non-default DPI settings, causing incorrect positioning of the native window. DisplayHeaderFooterproperty for built-in PDF printing being ignored. In the previous implementation, the headers and footers were not printed even if the option was enabled.- Event handlers being specified through the designer. Before the fix, specifying the event handler in the designer led to ignoring the 
BrowserTypeandURLproperties. - Improper popup sizes provided to the 
PopupContainerin the environments with the non-default DPI settings. 
Follow @DotNetBrowser to get notified of the library updates.
Subscribe to our RSS feed to get instant updates on new releases.
Subscribe to get notifications about the latest releases.