-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] _checkPrototype function loops indefinitely when calling Invoke-WebRequest cmdlet against a docs.microsoft.com webpage #31
Comments
Another variant (execution mode) as #19 |
Originally opened in Application Insights repo as microsoft/ApplicationInsights-JS#1534 |
[BUG] _checkPrototype function loops indefinitely when calling Invoke-WebRequest cmdlet against a docs.microsoft.com webpage #31
The work-around for this is for the hosting page to include the |
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? |
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. |
[BUG] _checkPrototype function loops indefinitely when calling Invoke-WebRequest cmdlet against a docs.microsoft.com webpage #31
Released in v1.1.2 on 4/19/2021 |
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
Invoke-WebRequest -Uri https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/windowsdesktop-whatsnew
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:
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
The text was updated successfully, but these errors were encountered: