WebBrowser Hosting Rules: Navigation, Drag-Drop and Script Errors (WPF)
If you have read the WinForms editor's hosting rules, you may expect the same constraints here. They do not apply. The WPF HTML Editor hosts the native System.Windows.Controls.WebBrowser, not the WinForms control, and although both wrap the same MSHTML engine behind a shared IWebBrowser abstraction, the WPF host tolerates -- and in one case requires -- the opposite settings. This page documents how navigation, drag-drop, and script-error suppression actually work in the WPF editor, and where the corresponding code lives.
Quick reference: WPF behaviour vs the legacy WinForms rules
| Concern | WinForms rule | WPF reality |
|---|---|---|
| Navigation lock | Set AllowNavigation = false on the editor; never on preview | No AllowNavigation property exists. A Navigating handler cancels navigation on the editor only; the preview is never locked |
| Drag-drop | Keep AllowWebBrowserDrop out of the designer file | No designer file. Maps to WPF AllowDrop through the adapter; forced off on the preview browser in code |
ScriptErrorsSuppressed | Must be false on the editor | Intentionally true on the editor -- the opposite |
| Parent container | Never put the editor on a Panel | Editor sits inside DockPanel > Grid > Border and works correctly |
| MSHTML interop | Old EmbedInteropType / .NET 4.0 warning | Identical NuGet package; the warning is obsolete on both |
Navigation lock: there is no AllowNavigation in WPF
System.Windows.Controls.WebBrowser has no AllowNavigation property -- that is a WinForms-only feature. The WPF editor instead attaches a Navigating event handler that cancels every navigation attempt, and it attaches that handler to the editor browser only, never the preview browser (WpfHtmlEditor.xaml.cs, lines 618-622). The handler is attached after the initial document load completes, not in the constructor, because attaching it earlier would cancel the deferred initial navigation and leave the document without a body element.
The net effect matches the WinForms intent: the editor is navigation-locked, the preview is free to render embedded media.
Drag-drop in WPF: AllowDrop through the adapter, no Designer file
WPF has no WinForms designer file, so the "delete the line from the designer" rule has no meaning here. The browsers are created in code and added to a DockPanel at runtime. The abstract AllowWebBrowserDrop member maps onto the WPF WebBrowser.AllowDrop property inside WpfWebBrowserAdapter (lines 166-170), and it is forced off on the preview browser in SharedEditorHelpers.cs (lines 522-523) when entering preview mode. There is no design-time editing surface to protect, so the WinForms drag-drop rule simply does not exist in the WPF world.
Why WPF tolerates a panel parent and ScriptErrorsSuppressed = true
The two WinForms conditions that protect the MSHTML edit surface are inverted in WPF -- on purpose:
- The WPF WYSIWYG browser is nested inside DockPanel > Grid > Border (it is created in code and added to the template's
_mainControlsPlaceholderDockPanel at runtime) and the edit surface still works. The native WPFWebBrowserhosts the ActiveX control through its own HWND interop, so re-parenting does not disturb it the way the WinForms control is disturbed. - The WPF editor browser explicitly sets
ScriptErrorsSuppressed = true(WpfHtmlEditor.xaml.csline 780). The adapter implements this by reflecting the private_axIWebBrowser2field and invoking the COM "Silent" property (WpfWebBrowserAdapter.cslines 175-191).
Because the hosting mechanism is different, the WinForms restrictions are unnecessary here and forcing them on would not improve anything.
MSHTML interop is identical to WinForms (NuGet, no EmbedInteropType)
The legacy ".NET 4.0 / EmbedInteropType = true" warning for MSHTML.dll is obsolete for the WPF editor too. The WPF project references the same NuGet package as WinForms -- Unofficial.Microsoft.mshtml.NetStandard version 7.0.3300.2 -- with no COM reference and no EmbedInteropTypes setting, across target frameworks from net45 to net10.0-windows. Treat the old warning as history.
Do not "fix" the WPF editor to match the WinForms rules
If a maintainer carries the WinForms checklist into the WPF code -- moving the browser out of its panel, or flipping ScriptErrorsSuppressed to false on the editor "to match" -- they will change working behaviour for no benefit and may reintroduce the very script-error dialogs the suppression exists to hide. The two editors share an interface, not a hosting model. The WinForms-side reference is the mirror of this page in the WinForms product's Known Issues category.