SAPIEN Forums

Hi all,

I create a GUI tools which has a web browser to browse a URL which is a web app own by IIS. It works fine in my last project. I will call this app as version 1.
But I recently create another GUI tools to browse the same URL. This is the version 2.
Now in version 2, It said my browser has disable the localstorage. I cannot access this URL in this version 2.

I double checked 2 GUI tools built by PowerShell Studio 2019. All properties are set to the same. And this URL can browse in version 1 and IE. But don't know why it cannot in the new version.

I also checked the IE security setting for the "Enable DOM Storage", it won't help. I even doubt that is not the IE cause this issue. If IE settings cause this issue, it should not work in version 1 either.

How can I solve this issue?
Any suggest will be appreciated!

The settings in question are set by the system and IE and not by the script or PowerShell. That can also be set by AV software or by Group Policy. The issue is not a scripting issue.

The other possible issue is that you have some problem with how you have coded the browser control.

From the information given there is no clear way to determine what is going wrong.

Thanks for your reply! The issue is resolved.
I found that is caused by Test-Connection. I try to use Test-Connection to test server connection before I submit an Invoke-Command job. Don't know why this CMDLET will cause this issue. Once I remove the Test-Connection. Issue has gone.
Now I changed to use ping to replace the Test-Connection. It works fine.

I wanted to add to this thread that I have the same problem with the WebBrowser control. If I do a Test-Connection before using it, the navigation fails. If I comment out the Test-Connection, it is successful. Strange.

One thing to note, when using the WebBrowser control. The control forces the process to run more isolated for security purposes. I suspect it is possibly the AV software or some enforced IE security.

You can also easily use Net Ping class.

Pinging the target is quite unnecessary because Invoke-Command and the WebBrowser both do teh same test. Just trap the exception and you have accomplished the same result with no unnecessary uncooperative code needed.