Introduction

If the .NET WebBrowser control shows JavaScript error dialogs, the immediate goal is usually to stop those dialogs from interrupting the desktop application. The deeper issue is that the control is built on the legacy Internet Explorer engine, so script problems and compatibility quirks are part of the environment, not just of the page. You can suppress the dialogs, but you should do it with a clear understanding of what is being hidden.

WinForms Has a Direct Property

In WinForms, the easiest fix is to suppress script error dialogs through the built-in property.

1using System;
2using System.Windows.Forms;
3
4public partial class MainForm : Form
5{
6    public MainForm()
7    {
8        InitializeComponent();
9        webBrowser1.ScriptErrorsSuppressed = true;
10        webBrowser1.Navigate("https://example.com");
11    }
12}

This keeps the browser control from showing modal JavaScript error popups to the user. The page may still have script problems, but the control will not interrupt the application with dialog boxes.

WPF Requires Access to the Underlying ActiveX Control

The WPF WebBrowser wrapper does not expose the same property directly, so developers often set the underlying ActiveX browser's Silent flag through reflection.

1using System.Reflection;
2using System.Windows.Controls;
3
4public static class WebBrowserExtensions
5{
6    public static void SuppressScriptErrors(this WebBrowser browser, bool hide)
7    {
8        var field = typeof(WebBrowser).GetField(
9            "_axIWebBrowser2",
10            BindingFlags.Instance | BindingFlags.NonPublic
11        );
12
13        var activeX = field?.GetValue(browser);
14        activeX?.GetType().InvokeMember(
15            "Silent",
16            BindingFlags.SetProperty,
17            null,
18            activeX,
19            new object[] { hide }
20        );
21    }
22}

Used from the window:

1public MainWindow()
2{
3    InitializeComponent();
4    Browser.SuppressScriptErrors(true);
5    Browser.Navigate("https://example.com");
6}

This approach is common in older WPF applications, but it is also a reminder that the control sits on legacy browser infrastructure.

Know What Suppression Does and Does Not Do

Suppressing script errors changes the user experience, not the page behavior. The site may still fail to render correctly, buttons may still stop working, and client-side logic may still break. All you changed is whether the user sees modal error dialogs.

That means suppression is reasonable when:

1. You fully control the embedded page and know the errors are harmless.
2. The app is an internal tool where a dialog is worse than degraded page behavior.
3. You log the failures elsewhere and do not need end users to respond to them.

It is much less reasonable when the page correctness actually matters and the app is silently masking real failures.

The Rendering Engine Matters

The WebBrowser control uses the Internet Explorer rendering engine, which is old and often incompatible with modern JavaScript-heavy sites. If a current web application behaves poorly inside the control, disabling script errors may hide the symptom while leaving the root problem untouched.

For example, if the embedded page expects a modern JavaScript runtime, the better fix may be:

1. Serve a simpler compatible page.
2. Stop embedding that site with WebBrowser.
3. Move to a modern browser control such as WebView2.

That architectural decision often matters more than whether the error dialog is visible.

Use Logging During Development

A good practice is to suppress dialogs in production-like UI while still keeping enough visibility during development to catch page problems. If you own the page, log client-side errors to the console or to an application endpoint. If you do not own the page, at least verify that the user workflow still works when dialogs are suppressed.

Suppressing errors blindly can make debugging harder later because the application becomes quiet while the embedded page is still failing.

Prefer a Modern Control for Modern Sites

If the project is still actively maintained and the embedded content is modern web content, migrating to a newer browser control is usually the stronger long-term answer. The WebBrowser control can still be useful for legacy intranet pages or tightly controlled HTML, but it is a poor fit for many current sites.

In that sense, disabling JavaScript errors is often a tactical fix, not a strategic one.

Common Pitfalls

• Suppressing script error dialogs and assuming that means the page is now functioning correctly.
• Using the WinForms property name in WPF, where the wrapper does not expose it directly.
• Ignoring that the control uses the Internet Explorer engine and may simply be incompatible with the embedded site.
• Hiding errors in development and then losing visibility into real page failures.
• Treating dialog suppression as a substitute for choosing the right browser control.

Summary

• In WinForms, use ScriptErrorsSuppressed = true to hide JavaScript error dialogs.
• In WPF, developers commonly set the underlying ActiveX browser's Silent property through reflection.
• Suppression hides dialogs, but it does not fix the underlying page or script errors.
• The legacy Internet Explorer engine is often the real compatibility constraint.
• For modern sites, a newer browser control is usually a better long-term solution than just hiding errors.