IE8 moves behind other windows when desktop shortcuts used and multiple tabs open (Needy state needy fixing) RRS feed

  • Question

  • When opening a website via desktop shortcuts, when a few tabs are already open in IE8, and when there are one or more other overlapping windows present, the IE window moves to the background (if it had focus), or doesn't get focus (if it didn't already have focus). 


    I've carefully isolated the problem as follows:  This is all IE8 on Windows 7 Enterprise x64 by the way, which apparently has more than a few gremlins - (I'm still grumbling about changes to Windows Desktop Search for network drives on 64 bit Win 7, but that's another thread entirely).  Anyway, I'm hoping this isn't x64 related, and that perhaps there's an idea out there.

    The computer is IE8 on a Windows 7 Enterprise  x64 machine in a somewhat tightly restricted corporate domain.  I do have local administrator access, but some things are still locked down from me.  The computer is mostly all patched up, but corporate IT controls when Windows Updates are applied.

    I've saved shortcuts to websites on my desktop, and assigned shortcut keys as follows:  shift-alt-control-G goes to Google, shift-alt-control-Y to Yahoo, shift-alt-control-M to www.moffitt.org, and shift-alt-control-B to Bing.  Also (more on this later) shift-alt-control-N to Notepad and shift-alt-control-L to Calculator). 

    And I have another window open (One or more) that overlaps with where the IE window is.  

    (a) Things work as expected, assuming IE was previously inactive, or assuming IE was active but no more than two tabs have been opened so far. The requested website (the target of the shortcut) opens as expected, with IE and that site in the foreground (a.k.a. with focus).  While opening, If IE wasn't open already, the taskbar doesn't blink orange at all.  If IE was already open when the new tab opens as expected, the taskbar blinks orange once then reverts to the normal color.  

    (b) Usually, the shortcut click or shortcut key-press that opens the fourth IE tab is where it starts to behave strangely (assuming at least one overlapping other window is open):  IE will successfully open the website in a new tab, but now, IE is behind all other open windows.  In conjunction with moving IE to the background, the IE entry on the Windows taskbar flashes (a.k.a. blinks) softly in orange 7 (seven) times, then stays glowing orange until clicked on.  (indicating "needy state", a Microsoft term for a window that needs/wants attention, but that was blocked from "stealing focus").   As alluded to in paragraph (a), the fact that the problem NEVER occurs until at least two tabs have been opened (thereby two instances of IE in task manager) tells me IE's Loosely Coupled IE processes are part of the issue.

    (c) Interestingly, this happens whether IE is already in the foreground or not.   If in the foreground when the problem occurs, IE moves to the background when I use the hotkeys (but subject to the above paragraphs (a) and (b), where in general, the problem doesn't occur until a few tabs are open within IE already).  And if not in the foreground, it stays in the background, rather than (if all was working properly) coming to the foreground.

    (d) And the problem happens no matter what method I invoke the desktop shortcut by:  The defined shortcut keys, clicking the shortcut icon on the desktop, or clicking the shortcut from the desktop toolbar as available from the toolbar.   Similarly, the problem happens whether IE is maximized or not.  (also subject to paragraphs (a) and (b) above where the problem doesn't occur until a few IE tabs are opened).  If you're wondering how I tested CLICKING a shortcut with IE maximized, it's by opting to show the Desktop toolbar on the Taskbar.

    (e) When the problem occurs, nothing appears to have focus.  IE has moved to the back, all the other windows still are in their relative positions.  If I recreate the problem with only one other window, that one other window won't have the focus.

    Interesting additional background and times where problem doesn't occur:
    * Creating a new user account (profile) didn't resolve.  The same problem occurred with the new profile too.  Clearing the browser cache (everything) didn't help.  And if any Best Buy techs are contemplating replying, reformatting the hard drive and reinstalling Windows won't help either and I'm not gonna do that...  ;-)

    * The problem did still occur in a Virtual Machine (Win 7) on the work computer.  Something similar (but not 100 percent exact) happens on my home computer (Windows 7 Home Premium, 64 bit, IE9):  IE will never give up focus when a site is opened via a shortcut on the home computer, but the taskbar will do the 7 flashes, and IE will NOT come to the foreground, if a different window was already on top.

    * I do seem to be experiencing another symptom that I came across from another post related to Windows Messenger:  When my IE taskbar icon flashes orange and I hover over it, the "live taskbar preview" of all the open tabs does not flash any of the previews, to communicate which of the tabs triggered the flashing  (the specific window triggering the flashing is supposed to flash).  There's a chance my problem isn't 100 percent the same though, since technically, my taskbar shouldn't be flashing in the first place, whereas the other poster's Messenger should have been (theirs had a real reason to be flashing).

    * The three already opened tabs can be anything: The problem is the same whether those first three were related to my shortcuts, or other completely different sites, or even just 3 or 4 empty tabs.  The very first  use of the shortcut (subject see (a) and (b) above) will trigger the problem and send IE to the background.

    * Same issue with 64 bit version of IE (which I can force by opening 64 bit IE with some other window first... subsequent shortcut keys open in this 64 bit browser, and as stated in (a) and (b), works as expected until the fourth or so tab opens.  Also, same issue with IE with extensions off, via Run Command "iexplore -extoff".

    * This problem behavior does NOT occur if I click an equivalent "Favorites" from within IE using the Favorites menu option or toolbar, same tab or in a new tab. 

    * The problem also doesn't occur if all other windows are minimized. 

    * The problem also doesn't occur if another window is open if that other window in no way overlaps with the desktop space that IE is using.

    * Calculator and Notepad:  I have windows desktop shortcuts with shortcut key definitions for them:  They always open as expected, in the foreground.

    * It appears to be IE specific:  I temporarily (for testing this problem) made Firefox my default browser, and I could never recreate the same problem while Firefox was the default browser.  No matter what I did, Firefox always came to the foreground or remained in the foreground every time.

    What it's NOT:
    There are a fair amount of people who have problems with ALL their programs opening in the background all the time, and for many of them, a fix to registry entry ForeGroundLockTimeout helped them.  My problem is different, (a) it doesn't happen with all programs, only with IE shortcuts (b) it doesn't happen all the time, and (c) I tried the ForeGroundLockTimeout anyway, and it didn't help.  My other program shortcuts are all fine, and I only have the problem with IE when about three tabs are already opened.

    I came across a post or two that seemed limited to people with Microsoft keyboards, where there had been some issues with the "Microsoft Hardware USB Keyboard" driver and the Microsoft keyboard with its Calculator key .  For a few people, the calculator would open up not in the foreground, but one layer behind the top window.  So that problem had a few similarities, but lots of differences too.   By the way, I'm on a Dell Keyboard and Mouse, no MS hardware, and MS Intellitype not installed either (which was related to those people's problem somehow too.

    There are also a fair amount of people with problems WITH focus stealing.  My issue appears to be the opposite, an over-compensation that was supposed to prevent focus stealing, but instead turned into focus-losing.

    Graphics Driver:  Up to date.

    It's not a virus (or a tooma).  Computer is protected on many levels, full scans periodically, tightly locked down, and scanned with different brands of scanners from time to time.  And everything works fine, until IE is at 3 or more tabs already opened.

    So... any ideas?  Thanks in advance!

    (P.S. I posted this first to answers.microsoft.com, and a moderator there suggested I post here instead)


    • Moved by Brent Serbus Monday, October 24, 2011 6:32 PM moved per OPs request (From:Windows 7 Networking)
    Saturday, October 22, 2011 5:47 PM

All replies

  • Thanks for the reply.  I suppose the corporate McAfee could be adding its own layer of ingratiate-ware to make itself look like it's catching things, but I have my doubts:  (a) it works until after the third tab opens/opened, and (b) my test scenario is a variation of any order of 5 different sites, google, bing, yahoo, and two pages within my corporate intranet, one of the two completely javascript free.


    Also, I posted here per the suggestion of the Answers.Microsoft.Com moderator, and didn't notice until after my post that there is a "User Interface" forum here under Windows 7:  Would my post be better placed there?  If so, and if a mod. sees this, feel free to move the post.  It doesn't look like I can move it on my own.  Thanks!

    Sunday, October 23, 2011 9:38 AM
  • A couple new new pieces of follow-up: 

    • My stated problem doesn't occur when I type in a shortcut (http://www.google.com) into the Windows RUN window (winkey-R or Start Menu/RUN), and repeatedly invoke IE by typing in a web address.  Whereas the desktop shortcut will eventually (third tab or higher) lead to the entire IE window going to the background, typing in the shortcut into the RUN window never causes IE to move to the background.
    • A partially similar problem occurs on my other Windows 7 machine (Windows 7 home premium with IE9):  What's similar is: If IE doesn't have the focus already when a desktop shortcut key to a web page is pressed, the new tab opens, and IE doesn't come to the foreground (as in, with focus).  What's different is: If IE did have the focus, the focus is never lost when I hit my desktop shortcut key or click on the shortcut.
    Wednesday, October 26, 2011 6:31 PM
  • (P.S. I posted this first to answers.microsoft.com, and a moderator there suggested I post here instead)



    So, have you tried gleaning any clues from running ProcMon yet?   ; )



    Wednesday, October 26, 2011 7:32 PM
  • I have not had time yet to run ProcMon and discover what arcane things it might barf out at me.  What should I look for?

     I don't know.  An undocumented relevant RegQueryVaue if you're lucky.

    Did you take time, (beyond offering that advice), to try this experiment yet?

    As I said when I made it I wouldn't be very hopeful, especially considering some of the seemingly random insertions that I reported (as seen via Flip-3D).   Also, it is not something that bothers me enough to make the amount of effort it would undoubtedly require to find a workaround.   Typically once you have done all the necessary analysis (e.g. using black box reverse engineering without access to source or program documentation) you can discover that the behavior makes some kind of sense, so the most likely result of all your efforts even if you do manage to get a bug report accepted is a resolution of Closed:  WAD (or something equally useless like Postponed.)   ; }


    Good luck


    Wednesday, October 26, 2011 9:01 PM
  • IE should not be displayed like that. Instead Windows 7 should show screen minis of the windows when you move the mouse over the IE icon

    You're referring to the row of flashing IE icons above?  Such a presentation would be possible depending on one's Taskbar settings.   E.g. Taskbar buttons:  Never combine.   Also, I think you are referring to an Aero Preview feature, so mousing over Taskbar icons doesn't necessarily have to do anything--similar to what happens in XP and Vista.   I'm not sure where you would go to disable it.   I think one way it would happen is just not to have an Aero-capable video card and driver.  

    But for this discussion what is important to realize is that when a Taskbar icon flashes it represents something that has happened to a task in a background window.  Many people want that feature and in fact might want to be even less aware of such events.   For example, in my case, I use Taskbar's Auto-Hide  option, so when a Taskbar icon starts to flash my Taskbar stops hiding and then is almost as disruptive as if it had interrupted by becoming the top window.

    My guess is that the reported symptom is just a quirk of the implementation of that feature but we really need to analyze the sequence of events that these observations are based on.   ProcMon's Process and Thread activity trace might even be sufficient to start that understanding.   At the same time ProcMon's RegMon trace might show that there are some tuning options available which could help modify whether they need to happen this way at all,  e.g. some kind of compatibility switch to make it more interrupting, e.g. the way that XP is by default.   ; )



    Thursday, October 27, 2011 6:04 AM
  • If you're wondering how I tested CLICKING a shortcut with IE maximized, it's by opting to show the Desktop toolbar on the Taskbar.

    @ John

    I have just realized that this implies that you don't use Auto-hide for the Taskbar but bringing the Taskbar out of Auto-hide is how IE windows can lose focus (the disruption I mentioned caused by flashing a Taskbar icon), so I'm wondering if you are seeing the same effect of the Taskbar (e.g. explorer.exe) getting focus but without Auto-hide actually being involved.   Have you tried testing with Taskbar's Auto-hide enabled to compare the symptoms you get then?




    Thursday, October 27, 2011 2:05 PM
  • I double-clicked the desktop shortcut again, and a new tab appeared in the same IE9 window, with focus on that new page.

    So this must be saying something about your Tab options which it may help to make explicit.

    E.g. I'm now testing on W8 Preview with IE10 in Desktop mode and dragged this to my Desktop


    (after doing a Ctrl-f Find for  EFBEA0 ICIM)   ; )

    Doubleclicking on the new Desktop shortcut after that just launched new instances of IE10.  I quit after 7 of them.

    FWIW my Tab options supposedly request a new tab for everything, e.g. new tab for a popup and new tab for a request by another program (probably ipoint.exe in this case because I was using my mouse's doubleclick button.)   ProcMon could show me for sure but I haven't installed it yet in this partition.

    So, should I open an incident for W8 Preview IE10 Desktop mode?   <eg>



    Thursday, October 27, 2011 3:23 PM
  • I'm now testing on W8 Preview with IE10 in Desktop mode and dragged this to my Desktop

    Oops.   That wasn't a Desktop shortcut (aka .url file) which got created.  It was a pinned website.   When I corrected that by dragging while holding down a Shift- key and then retesting I found that this will not be a valid test of this incident's scenario in W8 Preview IE10 Desktop.  The reason is that this launches IE10 Metro mode (chromeless).  (Surprise for me.)

    So now it looks that it could also be helpful to clarify if you are all using Internet Shortcuts (.url files), Desktop Shortcuts (.lnk files) or Pinned Websites (.website files)--and perhaps consider using one of the other type of shortcuts for a possible workaround.




    Thursday, October 27, 2011 3:41 PM
  • Have you tried testing with Taskbar's Auto-hide enabled to compare the symptoms you get then?--


    I just tested with Auto-Hide (I hadn't before, and you were correct, I don't use Auto-Hide).  Same set of results, though.  

    I'm also playing with Process Explorer, but for now, there's a severe case of information overload with its prolific output, too much to compare item by item right now.  I'll get back on that when I have a chance.

    To answer another question, my desktop shortcuts up to now were all ".lnk" file extensions, that reside on the desktop itself.  (For most of these, I create a favorite from within IE's Favorites menu, then copy the favorite, then "paste as shortcut" to the desktop.   Based on your suggestion, I tested ".url" type shortcut on my desktop also (by right clicking on desktop, choosing "create shortcut", typing in a web address, and doublechecking the file type of the created shortcut.  The same behavior occurs.  

    I realized there was one other thing I hadn't tried yet, but it made no difference: I put both .lnk and .url shortcuts specifically on the start menu, where I could click two ways: Click and release the start button, then click and release the link, or Click the start button, but don't release until I moved the pointer over the link, then release:  Same behavior.

    And another thing: pinning IE to the taskbar, then invoking shortcuts as they appeared on the list of shortcuts from clicking the taskbar icon (under the "Frequent:" category).  Those opened as expected, without losing focus, as many tabs as I wanted.  Once I clicked a link any other way (shortcut key, shorcut click, etc.), it was back to the background/flashing taskbar/etc.

    Another phenomemon, probably related, and definitely interesting:  I created a .lnk desktop shortcut to "about:blank", and no matter what, that ALWAYS opens a new instance of IE, but in the background, with the taskbar flashing orange 7 times.


    • Edited by johnqflorida Thursday, October 27, 2011 8:39 PM clarified comment
    Thursday, October 27, 2011 8:27 PM
  • OMG!   Ok, I just figured it out/fixed it.  TabProcGrowth in a variety of ways (missing, too low, or not zero (although zero is a bad idea, keep reading) is the culprit.  At least, it was in my case.  (I even logged off and back on before celebrating and proclaiming the issue solved).

    It turns out I may have been drinking at work when I tried registry setting "TabProcGrowth" earlier ;-).   I DID change TabProcGrowth earlier, but I had found it in my registry via a search and didn't pay close enough attention, so I changed the wrong TabProcGrowth, one that appeared in a hive for unattendedbackups... How embarrassing! It should actually be changed or set in HKCU\Software\Microsoft\Internet Explorer\Main.  In my case, my computer didn't have a TabProcGrowth entry at all in the correct place.

    So, I added it, correctly this time.  (Reference article:  http://blogs.msdn.com/b/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx.  (I'm guessing IE assumes "3" if the registry entry isn't found).

    My initial experiment, was to the "it works, but it isn't a good idea" value of zero.  Instantly, everything worked.  As mentioned in the article above though, running with tabprocgrowth at zero means IE8 is no safer or more stable than IE7: one crash in one tab brings all the others down with them; and in theory, one click on a rogue site that does cross-site-scripting will expose all your other tabs info and cookies to the bad guys.

    So I experimented:  Set it to 3, and everything works until the 4th tab.  Set it to 7, and everything works until the 8th.  I'm a heavy tab user.  I set mine to 15, and now everything works until the 16th tab.

    I recommend setting it to however many tabs you expect to use at a time, and NOT setting it to 0, which is less safe.  Don't sweat the extra processes unless they slow you down, that's what the swap file is for!  And cheap memory.  And big hard disks.  And fast CPUs.

    As a sidenote, mine only worked with integer settings:  The article above implies that "1" made it open a new process for each tab, but for me, it just made IE go to the background on the second tab open.  Similarly, I tried making the registry entry a string, and "small", "medium", and "large", and "Small", "Medium", and "Large" too, and those didn't work either, the words went back to the 3 tabs and you're out scenario.  I'm sticking with the integer approximating how many tabs I'm likely to need, because at least it works now.

    I'm now happy:  Thanks Robert, I may have never noticed my earlier error without running Process Explorer, thanks everyone else, and good luck to you, "" (blank name person).  Let me know if this fixes you up?  And I hope this helps other people too!



    Thursday, October 27, 2011 9:22 PM
  • @Vegan

    Thanks to you too!  Didn't mean to leave you out.  

    I use Firefox for many things too (although FF6 and 7 still haven't completely eliminated the freezing bug for all users, including my home machine).  

    All the different browsers have their strengths and weaknesses, and  I use them all for various reasons, or just to keep my head straight when I have to have too many things open at once.  To be fair, IE holds its own in many ways.  It's web developer tools are quite nice, and with IE8 and higher, the developer tools don't open any more when you type an upper case "R"... ;-)  And I like the way IE color codes new tabs opened as a result of "Open in a new tab" to keep things organized.  

    I have a love/hate relationship with Google Chrome:  It exposes a form of history sniffing, if you look closely at the ads that some (not all) sites throw.  Imagine the coincidence that ads related to sites you've visited recently show up!   And Opera recently resorted to sleaze, where the "Make Opera my default browser" checkbox is set to YES, and is tucked away on an alternate (not the focused tab) during install.  So old IE has its share of redeeming qualities too!

    Thursday, October 27, 2011 9:50 PM
  • Another phenomemon, probably related, and definitely interesting:  I created a .lnk desktop shortcut to "about:blank", and no matter what, that ALWAYS opens a new instance of IE, but in the background, with the taskbar flashing orange 7 times.

    Another peculiar thing about that is that about:  starts  iexplore.exe 64-bit.





    Friday, October 28, 2011 3:00 AM
  • So I experimented:  Set it to 3, and everything works until the 4th tab.  Set it to 7, and everything works until the 8th.  I'm a heavy tab user.  I set mine to 15, and now everything works until the 16th tab.

    Good work.   This reminds me that I once set it to 100 and found that there is a much lower de facto maximum for it (at least on a 4 GB 64-bit machine).   I can't remember what the metric was...

    Found it here (emphasis added):



    So, I tried setting TabProcGrowth to 101. That helps but the second loop still fails at a higher number.

    What finally worked is turning off Tabs *and* leaving that TabProcGrowth setting. Even then I still saw far fewer processes than I was expecting.

    C:\>tasklist /v /fi "Imagename eq iexplore.exe" | find "iexplore.exe" /c

    So it looks as if there is an undocumented upper limit to TabProcGrowth after which the user's wishes are ignored?




    Friday, October 28, 2011 3:37 AM
  • It dawned on me on the ride home:  It's nice to have an explanation/solution/workaround, but it's still a bug.  Moving the window out of focus just because a new process starts isn't correct behavior.   Also, TabProcGrowth wasn't in my work or home computer's registries at all (at least, not in the hive as documented in the IE product blog), for something so important (to security and stability), seems like the entry should exist on all computers, while not triggering the loss of focus problem.

    And "", I think you're correct, I never noticed this with Vista... although I mostly dodged having to use Vista much.  To be fair, Vista got quite usable after a while, and if you tilt your head and squint your eyes, much of Windows 7 just seems to be Vista wearing a disguise.


    Friday, October 28, 2011 5:29 AM
  • Groan... Ok, it's much improved, almost completely solved for opening new tabs for the first time or for the first time after a pause, if there is a proper TabProcGrowth setting.

    However, there can still be problems until the process-opening/reusing problem is fixed.  

    • Assume that in advance, you've set TabProcGrowth to a satisfactory number for your own usage patterns, let's say 15.
    • Watch the processes: Task Manager is fine for this, just to keep a simple count  of how many instances of IE are running):
    • And if you open 10 tabs, each new tab (as it opens) creates another instance of the iexplore process, meaning you'll have 11 iexplore.exe process (1 process per tab plus 1, usually).
    • Then close 5 of them.  You would think/hope/expect the 5 closing tab process would terminate instantly, wouldn't ya?  But they don't close instantly: they take about 30 to 45  seconds to close.
    • Before that 30 seconds expires, reopen a sixth tab, seventh, eighth, ninth, and tenth: New processes do NOT get created, because the already running processes 6 through 10 are apparently recycled, AND opening tabs 6 through 10 via a desktop shortcut again triggers the "back to the background" bug. 
    • Then (still in the 30 second timeframe) open tab number 11.  It opens nicely, in the foreground, since a totally new process is needed for this newly created 11th tab.
    • Repeat the process (open 10 tabs then close 5), but this time keep an eye on Task Manager, and wait for the processes related to the 5 closed tabs to close.  Then, open new tabs via a shortcut.  Now, the back-to-the-background bug won't occur.

    Conclusion:  It's "re-using a process" that triggers the bug.

    Assumption: (What a scientist!  I present my assumptions AFTER my conclusion) - My original issue when problems occurred after the third tab, which means that Windows 7 assumed a TabProcGrowth of 3 when there wasn't a TabProcGrowth entry in the registry.


    • Edited by johnqflorida Friday, October 28, 2011 1:14 PM fix more typos
    Friday, October 28, 2011 12:26 PM
  • So as far as the original topic, the losing focus when a tab is opened by a shortcut, etc. (as discussed throughout this thread):  It seems that we have an explanation and we have a workaround, and it seems (in my opinion) that we have pretty clear evidence of a bug, including  reproducible steps to recreate the bug.  

    What's the next step?  Can an MVP beckon a moderator/Microsoft employee to review and submit this through whatever channels are in place?

    Tuesday, November 1, 2011 2:39 PM