[BUG] _checkPrototype function loops indefinitely when calling Invoke-WebRequest cmdlet against a docs.microsoft.com webpage

[MSNev]

Description/Screenshot

This is related with the issue described at https://docs.microsoft.com/en-us/answers/questions/329655/powershell-invoke-webrequest-to-httpsdocsmicrosoft.html. Upon debugging the issue, it seems we loop indefinitely in a javascript function from this SDK, hence this issue.

The goal here is to verify that changes have recently been done in this area and if any IE quirk may need to be accounted for.

Steps to Reproduce

1. Open a PowerShell command line and type in the following command:

Invoke-WebRequest -Uri https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/windowsdesktop-whatsnew

2. The command may never return and you'll see powershell.exe going 100% CPU indefinitely

From the Invoke-WebRequest documentation:

The Invoke-WebRequest cmdlet sends HTTP and HTTPS requests to a web page or web service. It parses the response and returns collections of links, images, and other significant HTML elements.

This parsing is performed by using IE's mshtml.dll module, which may be part of the problem. Inspecting the CPU hogging PowerShell process, it seems we loop indefinitely in the following function:

	function _checkPrototype(classProto, thisTarget) {
        var thisProto = _getObjProto$1(thisTarget);
        while (thisProto && !_isObjectArrayOrFunctionPrototype(thisProto)) {
            if (thisProto === classProto) {
                return true;
            }
            thisProto = _getObjProto$1(thisProto);
        }
        return false;
    }

• OS/Browser: Windows 10 20H2
• SDK Version [e.g. 22]: latest stable
• How you initialized the SDK:

Expected behavior

The command returns with the DOM elements parsed. This can be observed by targeting any other URL for the Invoke-WebRequest cmdlet, not matter how complex the page may be.

Additional context

This is affecting enterprise customers that rely on this method to parse docs.microsoft.com content for certain internal processes.

Originally raised by @apmpinho

[MSNev]

Another variant (execution mode) as #19

[MSNev]

Originally opened in Application Insights repo as microsoft/ApplicationInsights-JS#1534

[MSNev]

The work-around for this is for the hosting page to include the X-UA-Compatible tag to force ANY mode of IE=9 or higher.
https://docs.microsoft.com/en-us/openspecs/ie_standards/ms-iedoco/380e2488-f5eb-4457-a07a-0cb1b6e4b4b5

[apmpinho]

There's nothing wrong with the site in that regard, if I access docs.microsoft.com directly in IE it loads in IE11 document mode (the page has a valid DOCTYPE declaration and that's enough).

It just happens that in this scenario PowerShell is basically a WebBrowser control host and IE7 document mode is the default there, as you can read at https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/general-info/ee330730(v=vs.85)#browser-emulation:

There's a way to force that within a given instance (https://www.cyotek.com/blog/configuring-the-emulation-mode-of-an-internet-explorer-webbrowser-control) but I guess that's more for the PowerShell folks at this point.

But this will all be kind of irrelevant if you're able to fix this on the server side: I can see you've added a change, when do you expect that to hit the live site?

[MSNev]

Yes, but if the site contained the meta-tag then this issue would not occur and you wouldn't need to jump through the hoops to force non-ie7 mode. That approach is not a scalable solution as it requires each individual to make the same change, whenever they use some sort of hosted IE instance (which is what power-shell is doing).

IE defaults to IE7 mode whenever it's hosted as an activeX, and the X-UA-Compatible meta-tag is required to tell the rendering instance to use a different execution mode. eg. Create a simple Windows Form app in Visual Studio and drop a "Browser" instance onto the form -- this will be IE running in IE7 mode.

The associated PR to fix this issue is enabling the DynamicProto component to effectively run in IE7 mode and will avoid the issue, but as the hosting page is still running in EcmaScript v3 (IE7) mode there will still be other JavaScript errors that occur for the page.

[MSNev]

Released in v1.1.2 on 4/19/2021