Jump to content
Sign in to follow this  
ako673de

Hidden IE-Window becomes unhidden with certain URLs

Recommended Posts

ako673de

I create an empty ("about:blank") IE window with _IEcreate and force it to be hidden. So far it works. Then I navigate to other URLs and especially with URLs of the form "192.168.xxx.xxx" suddenly the hidden IE window returns visible. I already read similar comments, which talk about new security policies in Vista, that cause new browser instances to pop up if security zone changes while browsing, but I don't have Vista, just XP, and I confirmed that now new browser instance is being created, just the exisitng one will unhide. I also tried to rehide it with _IEAction(...,"invisible") but that does not work until the URL loaded completely (because the unhiding process seems to take place somewhere in between the loading of a qualifying page), which is a too long time for my application.

I'm using IE8. Any ideas how to avoid this behaviour? Pls forget about those 5 ones given in the Autoit help regarding the "new instance" issue, I tried them all and none have any effect on my issue.

regards

ako673de

Share this post


Link to post
Share on other sites
DaleHohm

Get the hwnd with _IEPropertyGet and then use the standard WinSetState to hide.

Dale


Free Internet Tools: DebugBar, AutoIt IE Builder, HTTP UDF, MODIV2, IE Developer Toolbar, IEDocMon, Fiddler, HTML Validator, WGet, curl

MSDN docs: InternetExplorer Object, Document Object, Overviews and Tutorials, DHTML Objects, DHTML Events, WinHttpRequest, XmlHttpRequest, Cross-Frame Scripting, Office object model

Automate input type=file (Related)

Alternative to _IECreateEmbedded? better: _IECreatePseudoEmbedded  Better Better?

IE.au3 issues with Vista - Workarounds

SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y Doesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead?

Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble

Share this post


Link to post
Share on other sites
ako673de

I just gave it a try and here is what I experienced:

1) What you suggest does not work (any other or better), if _IEcreate is called with "hidden" option turned on (before WinSetState(...,@SW_HIDE)-ing it).

2) If I run _IEcreate in normal mode, then what you suggest works (at least sort of, because a flashing IE window is not very beautiful to see). But here it becomes strange: The IE still does not stay hidden forever! As far as I can see, it seems to depend somehow on user interaction with Windows itself, e.g. bringing certain windows to focus or foreground, or the like. At least it does not always happen after a fixed number of "_IENavigates" (to always the same site by the way!).

Conclusion: IE8 window still cannot be kept hidden under all circumstances.

Other ideas?

ako673de

Share this post


Link to post
Share on other sites
DaleHohm

I was specifically responding to your observation that _IEAction(...,"invisible") didn't take effect until the page load was done. The WinSetState should have no such limitation.

Dale


Free Internet Tools: DebugBar, AutoIt IE Builder, HTTP UDF, MODIV2, IE Developer Toolbar, IEDocMon, Fiddler, HTML Validator, WGet, curl

MSDN docs: InternetExplorer Object, Document Object, Overviews and Tutorials, DHTML Objects, DHTML Events, WinHttpRequest, XmlHttpRequest, Cross-Frame Scripting, Office object model

Automate input type=file (Related)

Alternative to _IECreateEmbedded? better: _IECreatePseudoEmbedded  Better Better?

IE.au3 issues with Vista - Workarounds

SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y Doesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead?

Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble

Share this post


Link to post
Share on other sites
ako673de

I was specifically responding to your observation that _IEAction(...,"invisible") didn't take effect until the page load was done. The WinSetState should have no such limitation.

Dale

_IEAction(...,"invisible") does it's work, even if the page is still loading. What I wrote was that while the page is loading this command CANNOT work because it does not know when during loading IE decides to unhide its window, and that's no other for WinSetState. The only temporary workaround would be to completely rewrite the _IENavigate-UDF to continuously rehide while waiting (for load complete or timeout).

However you would still be annoyed about IE spuriously popping up and back down (=flashing).

I think the only chance to overcome this issue is to tweak some IE8 setting (which for sure is some security related thingy) to stop it from unhiding, but I don't know which one. Putting the problem sites to "trusted sites" did not work...

Edited by ako673de

Share this post


Link to post
Share on other sites
ako673de

Argh!!! I just accidently deleted my last post, so don't wonder if the following text reads some kind of different:

As announced I wrote my own code to keep IEs hidden - well, at least as good as possible:

The essential idea is that windows at least appear to be hidden, if they are not visible. So I move hidden IEs to the lower right screen corner. This property can then later be used to identify IEs that should be hidden (but maybe no longer are). My function _IEMultipleLoadWait() does exactly this and it then automatically rehides the auto-unhiding IEs (which are already not visible but still reappear in the task bar).

While typing I thought that I could also boost this function a little bit: Because what the original _IELoadWait() is lacking of, is the possibility to handle more than one IE at a time (which however could be very useful for saving time if more than one page has to be loaded). My function therefore can wait for many IEs! And it can be interrupted by external events, which is another thing the original function is lacking of.

BTW: I'm still using _IEAction("invisible") because the latter is thousands of times faster than WinSetState and it works.

; Same as _IECreate() except that hidden IE is moved to lower right screen corner
Func __IECreate($Url="about:blank",$attach=0,$visible=1,$wait=1,$focus=1)
    $oIE=_IECreate($Url,$attach,$visible,$wait,$focus)
    If $visible=0 Then 
        _IEPropertySet($oIE,"left",@DesktopWidth-1)
        _IEPropertySet($oIE,"top",@DesktopHeight-1)
    EndIf
    Return $oIE
EndFunc
; Wait for multiple IE windows to complete or timeout. If $Abort becomes TRUE (possible only due to an Event!!!) it returns -1, else the bit coded completion state of all IEs
Func __IEMultipleLoadWait($oIEarr,ByRef $Abort)
    $cntIE=UBound($oIEarr)
    Dim $hidden[$cntIE]
    For $i=0 To $cntIE-1
        $hidden[$i]=(_IEPropertyGet($oIEarr[$i],"left")==@DesktopWidth-1)
    Next
    $completeMax=2^$cntIE-1
    $complete=0
    $tstart=TimerInit()
    While TimerDiff($tstart)<$__IELoadWaitTimeout And $complete<>$completeMax   ; Wait until timeout, all browsers complete or Exit requested
        If $Abort Then Return -1
        For $i=0 To $cntIE-1
            If $hidden[$i] Then _IEAction($oIEarr[$i],"invisible")
            If String($oIEarr[$i].readyState)="complete" Or $oIEarr[$i].readyState=4 Then $complete=BitOR($complete,2^$i)
        Next
        Sleep(100)
    WEnd
    Return $complete
EndFunc

However, if anybody comes across a registry hack to disable this IE8 behaviour I would strongly appreciate if you let me know. It is still a bit annoying to see the taskbar moving left and quickly back right when IEs unhide...

Edited by ako673de

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.