Legacy browser compatibility checklist
Use this checklist before assuming an old intranet or WebForms page needs full IE mode. Some pages only depend on older JavaScript and DOM behavior and can be tested in Chrome with scoped compatibility patches.
Try IE Compat Bridge Check product limitsGood candidates for a Chrome patch layer
Old JavaScript event patterns
attachEventinstead ofaddEventListenerwindow.eventorevent.srcElementreturnValueorcancelBubbleassumptions
Old navigation and frame patterns
- Frameset startup pages that load the real app later
Loading.htm?url=...redirect pages- Selected
document.framesaliases
Old picker and WebForms behavior
showModalDialogpicker flows- Legacy WebForms date controls
- Buttons or form actions that work in IE but do nothing in Chrome
Scoped internal testing
- The old page mostly opens in Chrome already
- You can test on a configured internal hostname
- You want macOS and Windows Chrome users to join validation
When to use real IE mode instead
Windows-only browser technologies
- ActiveX controls
- VBScript or COM integration
- Java applets or Silverlight plugins
Real Trident/document-mode dependency
- IE7 or IE8 document mode is mandatory
- The page renders differently because of the IE engine itself
- The vendor explicitly requires Internet Explorer or Edge IE mode
Practical test flow
- Open the old page in current desktop Chrome and note what breaks.
- Separate rendering problems from JavaScript interaction problems.
- Check whether the failing feature depends on ActiveX, VBScript, COM, applets, or Trident.
- If not, test a scoped JS/DOM compatibility patch on one hostname.
- Keep Edge IE mode or a Windows VM as the fallback for true IE-only dependencies.