Not every old business web app needs a full Internet Explorer environment.
That sounds obvious, but it is easy to miss when a legacy intranet, ERP, OA, or ASP.NET WebForms page fails in Chrome or Microsoft Edge. The first instinct is often to put the whole system into IE mode. Sometimes that is absolutely correct. Other times, the page mostly works in Chromium and only breaks on older JavaScript or DOM assumptions.
The useful first step is to separate those two cases.
Case 1: the page needs a real IE engine
Use Microsoft Edge IE mode, a Windows virtual machine, remote desktop, or another managed legacy-browser path if the page depends on:
- ActiveX controls
- COM integration
- VBScript
- Trident or MSHTML rendering behavior
- Browser Helper Objects
- Java applets
- strict IE7 or IE8 document modes
A Chrome extension or JavaScript compatibility layer should not be presented as a replacement for those requirements. If the workflow depends on the IE engine, the browser engine is part of the application runtime.
Case 2: the page mostly works, but old browser assumptions fail
There is another common category. The page loads in Chrome or Edge, authentication works, and the main UI appears, but a small set of old behaviors fails.
Examples include:
- empty frameset entry pages
- loading pages that do not finish redirecting
attachEventwindow.eventevent.srcElement-
showModalDialog-style picker flows document.frames- older WebForms date fields that call a calendar function on focus
For maintained source code, the best answer is still to fix the application. Replace old event APIs, remove synchronous dialog assumptions, and modernize generated WebForms scripts where possible.
But in many real organizations, the legacy page is owned by a vendor, frozen department system, or migration backlog. In that situation, a scoped compatibility layer can be worth testing before moving the whole workflow into IE mode.
A low-risk triage sequence
I use this sequence:
- Pick one legacy hostname.
- Pick one failing workflow.
- Confirm whether the failure is an IE-engine dependency or a JavaScript/DOM compatibility issue.
- If it is an IE-engine dependency, use IE mode or another real legacy runtime.
- If it is JavaScript/DOM compatibility, test a scoped compatibility approach on that one hostname.
- Keep permissions narrow. Do not grant broad access to every website just to test one old page.
The important point is scope. The safest test is not "make all old sites work." It is "can this one approved hostname complete this one broken workflow in Chromium?"
Where IE Compat Bridge fits
Disclosure: I am involved with IE Compat Bridge.
IE Compat Bridge is built for the second case only: legacy business pages that mostly run in Chrome, Microsoft Edge, or another Chromium browser, but still rely on selected IE-era JavaScript or DOM behavior.
It is not an Internet Explorer engine. It does not run ActiveX, COM controls, VBScript, Trident rendering, Java applets, Browser Helper Objects, or true IE document modes.
The intended test path is narrow:
- configure one legacy hostname
- grant browser access only for that origin
- reproduce one failing workflow
- decide whether a lightweight bridge is enough or whether IE mode is required
Decision guide:
https://ie-compat-bridge.kssicstudio.com/ie-mode-or-chrome-compatibility-bridge
Chrome Web Store:
https://chromewebstore.google.com/detail/ie-compat-bridge/blaopiiafdfificalgbkjnljbhmjojpa
The practical takeaway
Do not start by asking, "How do I make Chrome behave like Internet Explorer?"
Start by asking:
- Does this workflow need the IE engine?
- Or does it need a few old JavaScript and DOM assumptions patched?
That distinction usually decides whether the right path is IE mode, application modernization, or a small compatibility bridge while migration work continues.