From bug 474056, comment #54: > Out of the ten tabs that I have, only the > last one currently has a preview, all others just display a progress circle. > New tabs get a preview though Need to investigate this and find the cause. It seems as though the DWM isn't getting the thumbnail/preview.

I've been seeing the same thing, and there are no errors being shown in Console2 Error console. It seems to take a complete shut-down and restart of the browser to get the preview showing again, rather than the 'busy-halo'. Leaving it sit for extended periods of time, or refreshing the page does not clear the problem. It seems once it starts, its stuck until the restart of the browser. Still seeing the problem as I post this message, 10 of the 11 tabs are showing the 'busy-halo', using today's nightly build: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre Firefox/3.7 (.NET CLR 3.5.30729) ID:20091014045102

What about the JS Error Console? Do you have a consistent way to reproduce it?

Console2 enabled the JS error console by default I believe, and I'm not seeing any errors. Possible STR: (tricky at best) 1. Open ten (10) Tabs 2. Open the 11th tab and in that tab browse a few links on the site: bestbuy.com (don't think site matters) 3. Close the 10th tab, which puts you back on the new 11th tab. 4. Quickly go forward/back through the links you opened in the 11th tab, and then check AeroPeek, should get the 'busy-halo'. Now, over time and continued browsing you should eventually see all the tabs go to the 'busy-halo'.

Just noted, that once you have a tab in the 'busy-halo' mode, simply selecting the other tabs you have open, will result in the AeroPeek showing those newly selected tabs that you previously had open as 'busy-halo'.

Further: With 10 open tabs, I always have CNN as tab #1. Enter into Private Browsing Exit Private Browsing AeroPeek now will show tab #1 (CNN) as the 'busy-halo'

In another bug, Rob asked me: > Is there anything in your error console? Yes. The following messages in different order: 'tab is undefined' (WindowsPreviewPerTab.jsm line 514) 'NetUtil.newURI is not a function (WindowsPreviewPerTab.jsm line 123) 'this.previewFromTab(tab) is undefined' (WindowsPreviewPerTab.jsm line 515) Also, if you wait a minute or two (without having clicked the taskbar icon), do the progress circles resolve into a preview? They resolve to default application icon (not even the one this application uses). Then if I move my mouse away to hide these previews, and move it back on the window button later, I get busy circles for those tabs again.

(In reply to comment #7) > *** Bug 522385 has been marked as a duplicate of this bug. *** Good screen shots in that dupe.

(In reply to comment #6) > Also, if you wait a minute or two (without having clicked the taskbar icon), do > the progress circles resolve into a preview? > Most of the time when the tabs finally load, this goes away, I get previews. > the window button later, I get busy circles for those tabs again. But following some STR that Jim was looking into, I got one that is stuck on everytime I go back to taskbar previews. If you click on the one that is stuck, I see the busy icon for the browser preview too. I can click on it, but its not loading anything. Is it getting stuck in something like the bfcache?

Hovering over the stuck busy loading icon preview also shows a busy loading browser tab/window preview, but not loaded page.

Setting browser.sessionhistory.max_total_viewers to 0 (zero), which should disable bfcache as I recall.. makes no difference, with enough diligence I can still get the loading halo to appear. It also seems at times that restoring a 'recent closed tab' from the History menu item will cause 'other' tabs to go into showing busy halo, or in a case I just saw while posting this, the preview shows the tab but the tab itself instead of showing content has the busy-halo, just the opposite of what we are seeing.

If it matters, I see the same thing using IE7 on mozillazine website. Sometimes I just see an envelope in the preview for mozillazine.

If I have 1 or two stuck tabs, If I click on the stuck busy icon tab preview to activate that tab, but next time I go to the tab previews, it still thinks the active tab is the tab before I clicked on the stuck one. So this code never gets a chance to change active tabs. (In reply to comment #11) > just saw while posting this, the preview shows the tab but the tab itself > instead of showing content has the busy-halo, just the opposite of what we are > seeing. If we're just loading and assuming this is not stuck preview, is the preview doing a slight snapshot here? so if its got content, and you click reload, it seems that the preview is of the that snapshot before started over, maybe getting a busy icon preview or a white screen (blank tab) before the content comes back.

Rob, any chance you see the fix from bug 522416 have an effect on this here problem? I noticed this with today's nightly after bug 522416 landed yesterday that I can make a preview stuck by just having the mouse over the preview as its loading the webpage with only 1 tab open.

(In reply to comment #15) > Rob, any chance you see the fix from bug 522416 have an effect on this here > problem? I don't think so. The symptoms of bug 522416 are a hang of the entire browser. You need not preview for that to happen. I don't know the exact cause of this bug however so there's always a chance.

I can report that using an hourly build with bug 522416 that the loading circles are still alive and well....broken :)

I'm getting this with three tabs (screenie attached) - anything I can do to debug? Have we tracked down where we do the handoff to see if there's anything that blocks or waits for a callback that's not being received?

Please also see bug 522506, which, if it's not a dupe, it's definitely related.

I noticed some more odd behavior.. Now If I leave previews up for about 5 minutes a piece, and start closing tabs from the preview, the stuck preview will transfer itself to another tab preview and 2 stuck previews will resolve to the envelop icon at the exact same time. I couldn't seem to determine if it starts with https URL tab content and being logged in, or if its because we're closing tabs from the preview list or previews themselves causing previews to go stuck (doesn't appear to be reloading a tab). Questions I'm just trying to think of if the tab is doing work, what else do we know happens, what is the workflow: reflow? repaints? do certain types of websites cause the previews to become stuck by themselves more than others? are we seeing issues because we're trying to focus/view previews and the browser at the same time on certain website types? is decodeondraw is currently active? What role do Favicons play? bfcache?

I tried reproducing this today. Leaving the browser open with a bunch of tabs loaded. Best I was able to do was find some tabs showing the blank page with the spinning cursor in them. The preview popups over the icon all displayed correctly. On leaving the preview area and going back to it, the pages rendered properly. tricky!

We sure we should block on this?

Here is my user experience assessment of this after using the build almost everyday, even though we've discussed all this.. I think it boils down to this: Either we drop tab previews for 3.6.0 or we fix this bug.. because this bug just makes tab previews feature look bad from quality and UX perspective in general. Developers have done a wonderful job so far.. but we're not out of the woods yet. Alternatively, can we turn if off tab previews for 3.6.x till we find a fix? On a more technical assessment.. It seems to be that it this problem either starts because we're trying to preview while loading tabs, or it starts after we start deleting tabs, switching tabs and adding back tabs or it occurs on its own on some sites like Mozillazine or Bugzilla. And as Mike asked, is there some callback that doesn't happen, its like previews gets stuck in a blackhole and don't know how to recover back to working and create a domino effect. There is a cache and snapshot occuring also (rob is this working properly? maybe something doesn't get cleared). If those steps occur, then that seems to eventually lead to bug 522305, bug 522610 and bug 522506. But it seems even after bug 522416 was fixed to make http requests async, previews can still run sync due to something else, though fixing bug 522855 should put favicons into async too. I think we will have a better picture about this issue once bug 522855 is fixed though fixing bug 522305 and bug 522506 are important too, because they present UX issues also. I guess the only way to figure this bug out is to trace through the code/logic and see if/where it gets stuck or see if there is still some sync swimming going on here. Like anything else fixing one thing at a time till this gets knocked out may be the only option.

Unblocking, as we're not going to ship tab previews in Firefox 3.6 (see bug 525475).

I can confirm this bug , in fact i came here to post about it only Build tested = Firefox 3.6 Beta 1 (official)

Same thing happening to me. Any number of tabs open, my first tab almost always shows as the spinning circle. Refresh, new page, doesn't matter, I can't get rid of it.

After further investigation, I am not seeing us bail due to error on the codepath. I am going to look into the possibilites that either a) we aren't getting the notification from windows (seems unlikely) or b) we're somehow taking much too long to return to the callback. a nested event loop perhaps?

I was able to reproduce this at least 20 times so maybe it is some luck to help figure this out. 1) New profile, login to gmail, bugzilla and facebook. Tell Firefox to remember all of those passwords 2) Go to http://www.facebook.com/login.php to get this in the awesome bar 3) Make sure your have show my tabs and windows from last time enabled in the options menu 4) Close the bugzilla and facebook tabs 5) Have only the gmail tab open and be in your inbox 6) Close Firefox and open it back up (don't hit any other keys or move the mouse at any point after opening Firefox back up) 7) ctrl+t, type in fac and select facebook.com/login.php, hit down arrow key to select from awesomebar and hit enter -> type in password and/or just hit the login button 8) ctrl+t, type in bug and select bugzilla.mozilla.org, hit down arrow key to select bugzilla from awesomebar and hit enter 9) Click on the "my bugs" link under your saved searches at the bottom left of bugzilla 10) Click on the ID table to sort by ID (down arrow, ascending? direction) 11) Scroll down to the bottom of the page by manually moving the slider to the bottom of the page 12) Close the facebook tab using the tabbar close button without focusing it 13) Look at the previews by hovering over the firefox taskbar icon Should seen spinning circle

Getting docshell appeared to fail when progress circles were displayed. http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/TaskbarPreview.cpp#336

I also have this problem. Windows 7/FF3.6B1 obviously. Both blogspot tabs I have open are showing it, as well as bugzilla, while a lot of others are displaying correctly. Windows 7 version is RC, if that helps

Scutterman, see comment #25, Firefox 3.6 won't see this issue fixed. I'm also changing the target milestone to from 3.6 to 3.7 as per Mike, comment #25. Also changed platform from x86:All to All:Windows 7 as this isn't affecting anything outside of Win7.

Bug 521668 just landed on the trunk. Looks like it cuts back on the network parsing and makes more of the DOM async to avoid recursions. I was going to say it really helps this bug.. but... between the comments we have, it looks like https pages are having more issues than http pages. I tested this again with bug 521668 fixed. Having closed an http tab preview to the left of an https tab preview I then switched tabs via previews a few times and then the https preview went into busy circle and didn't ever recover. Maybe the tab next in line inherits a bad tab index (one that was just closed) or it drops a pointer from the preview list?

Docshell wasn't required here in the first place :)

This problem seems to be fixed in Firefox 3.6 Beta 2. It works a LOT better now.

(In reply to comment #34) > Getting docshell appeared to fail when progress circles were displayed. > http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/TaskbarPreview.cpp#336 (In reply to comment #38) > Created an attachment (id=410964) [details] > patch > > Docshell wasn't required here in the first place :) Is there a chance we can test a try-server build with this patch in place?

(In reply to comment #34) > Getting docshell appeared to fail when progress circles were displayed. > http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/TaskbarPreview.cpp#336 (In reply to comment #38) > Created an attachment (id=410964) [details] [details] > patch > > Docshell wasn't required here in the first place :) I could not reproduce this in the debugger - I was getting hangs w/o docShell being NULL. I'm not entirely sure why you think the docshell isn't needed - I'm pretty sure canvas needs it to draw/measure text (though our current drawPreview/drawThumbnail implementations don't require it). Nonetheless I plan to review the patch later this week to see if it does indeed fix the problem - at the very least it may give me some clue as to the source of the problem.

Still happens for me in Firefox 3.6 Beta 2, contrary to comment #39.

(In reply to comment #39) > This problem seems to be fixed in Firefox 3.6 Beta 2. It works a LOT better > now. It still happens for me in Firefox 3.6 Beta 2. (In reply to comment #41) > I could not reproduce this in the debugger - I was getting hangs w/o docShell > being NULL. I could reproduce it frequently and docshell becomes null whenever I see progress circle. > I'm not entirely sure why you think the docshell isn't needed - I'm > pretty sure canvas needs it to draw/measure text Is this an invalid code? http://mxr.mozilla.org/mozilla-central/source/content/canvas/src/nsCanvasRenderingContext2D.cpp#886 > (though our current > drawPreview/drawThumbnail implementations don't require it). That's the point.

I just thought I would add my 0.02$. It Still happens for me in Firefox 3.6 Beta 2. I have however discovered a way to reproduce this consistently. This is my first ever post and I have no knowledge in the source code or working with firefox's source. Basically my steps to reproduce were: 1. Installed Firefox 3.6 Beta 2. 2. Opened 3 tabs. Tab1 http://www.google.co.uk/ Tab2 http://www.facebook.com/ Tab3 http://www.youtube.com/ 3. Rolled over icon in the taskbar - all previews were working. 4. CLOSED THE 2nd Tab by clicking 'X' on the tab but not making it the active one. 5. Rolled over icon in the taskbar and what was now tab 2 ("http://www.youtube.com/") was no longer working. This happens every time I try this and it leads me to think that ... Isn't this just something as simple as Firefox getting confused with the ordering of the tabs and then the preview failing? I do do programming myself and it just strikes me as odd that for me personally, the previews work, UNTIL I close a tab. Are we definitely removing the reference to the tab in the preview list?

I've reproduced all the steps described in comment #44, even with a blank new profile, the same happened. NOTE: using Beta 2 for FF3.6

(In reply to comment #43) > (In reply to comment #41) > > I could not reproduce this in the debugger - I was getting hangs w/o docShell > > being NULL. > I could reproduce it frequently and docshell becomes null whenever I see > progress circle. I'm not sure it should ever be null unless we're in a weird situation where the tab preview is live but the document isn't. > > > I'm not entirely sure why you think the docshell isn't needed - I'm > > pretty sure canvas needs it to draw/measure text > Is this an invalid code? > http://mxr.mozilla.org/mozilla-central/source/content/canvas/src/nsCanvasRenderingContext2D.cpp#886 That code is invoked with mCanvasElement set to a non null value. We don't have an actual canvas element so we need to provide a docShell so that the other parts of canvas which need an nsIPresShell can function. > > (though our current > > drawPreview/drawThumbnail implementations don't require it). > That's the point. That doesn't help extension authors or other consumers who may want to use the text features.

Additional observations on the behavior of this bug: With 3 tabs open, tab 1 preview stops working. Close that tab (from the preview) and open a new (blank) one (going to number it tab 4), all previews ok. Reload the web page that was in tab 1 into the new tab. All previews working. Select tab 2 preview (working)((now tab 1 in the list)) - page displays following a short period of the windows spinner. Looking at previews, tab 2 has now stopped working, but others are ok. If you play around like this, you'll usually get 1 tab preview not working, but 2 others working. ... now here's the thing I just noticed - if you hover over a tab preview until Windows displays that tab's content, after a while ALL tabs will get the Windows spinner and no content, even if they're preview is still working... Could there be some page load / display issue going on with the main window which is somehow affecting / causing the preview behavior?

...sorry, meant to add a couple more things... Continuing from the above comment, reloading ANY of the tabs causes that tab's preview to stop working. And I'm currently using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091126 Firefox/3.6b2pre

Problems also seem to start when you have multiple tabs open, and then close all but one.

I am not seeing this behavior today with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100120 Firefox/3.7a1pre. Anyone else able to confirm this?

Yep, still there using latest hourly: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100120 Minefield/3.7a1pre Firefox/3.6 ID:20100120095940

This patch appears to fix the problem. As suspected, the doc shell disappearing was the problem. Previously we would use the docshell of the active tab. The bug would only exhibit itself when said docshell was garbage collected which only happens "some time after" that tab is closed.

(In reply to comment #57) > Created an attachment (id=425746) [details] > Use the docshell of the <browser> > > This patch appears to fix the problem. As suspected, the doc shell disappearing > was the problem. Previously we would use the docshell of the active tab. The > bug would only exhibit itself when said docshell was garbage collected which > only happens "some time after" that tab is closed. What about the case of moving tabs around? closing them from either the preview or the main tabbar? and inserting new ones and then closing others?

Well, I would like some additional testing. It was already rather hard for me reproduce it and I am not entirely sure I have fixed it. This patch is rather easy to apply by hand to an existing firefox build/installation since the .jsm file lives directly in the file system. Please do try it! I suspect there may be more than one problem (ex: maybe if the tab takes a while to draw we get the circles). Still, this appears to have helped at least one person and is at the very least a partial fix so I'd like to get it on trunk (ideally for the 1.9.3 alpha but we missed that) and see if it's still such a common issue for folks.

For those of us that have no clue where to start when applying patches manually, could you maybe throw this up on the 'tryserver' if its not going to land in m-c soon....

Close Firefox. Find the folder modules/ where Firefox is installed. Edit the file 'WindowsPreviewPerTab.jsm' in notepad. Replaced line 422: let preview = AeroPeek.taskbar.createTaskbarTabPreview(this.tabbrowser.docShell, controller); with let preview = AeroPeek.taskbar.createTaskbarTabPreview(tab.linkedBrowser.docShell, controller); Save, start Firefox. Seems to be working so far, I only see the spinning circles for a split second then the previews appear.

Of course as soon as I post that, I start seeing the progress circles again...on gmail at least.

I've been testing the patch for the past 8 hours and it seems to work fine. No circles for me anymore. Mozilla/5.0 (Windows; U; Windows NT 6.1; sk; rv:1.9.3a2pre) Gecko/20100206 Minefield/3.7a2pre with the patch applied

Screenshot showing a progress circle on cnn and also the modified line in the file.

I have not been able to confirm the thumbnails going bad but I have been able to reproduce rather successfully circles on the live preview if I reload all my tabs and cycle quickly across the strip of thumbnails. Usually one of the tabs in the middle of the strip will have a preview with circles. I added some printfs to the native code and we are indeed getting a request for the live preview and sending it the bitmap with no error returned by the API call. I'm tempted to call this a Windows bug because we appear to be doing the right thing.

I am able to reproduce if I apply my STR from comment 65 to IE8 so I am going to call it an OS bug. Kurt, do you have STR for the thumbnail circles? I have not been able to get that to reproduce for me.

Since applying the hack this morning, I haven't been able to reproduce the bug at all; so this fix is working 100% for me at the moment.

Rob, I got permanent progress circles after modifying the file too, I used a combination from comment 58 with random steps from prior posts about moving/dragging/closing/inserting tabs with a variation of websites like I had before. I didn't track a specific STR path other than what we've tried already. Eventually I get them since this is a typical usage scenario for me, and I still also noticed this: https://bugzilla.mozilla.org/attachment.cgi?id=406374 It sounds like it would be helpful to have a full debug build with a ton of printf data on this. (In reply to comment #66) > I am able to reproduce if I apply my STR from comment 65 to IE8 so I am going > to call it an OS bug. If we can prove that, maybe MS could work on a fix.

(In reply to comment #66) > I am able to reproduce if I apply my STR from comment 65 to IE8 so I am going > to call it an OS bug. I can confirm this. > > Kurt, do you have STR for the thumbnail circles? I have not been able to get > that to reproduce for me. I've only seen it once on gmail and once on cnn hours ago and haven't been able to reproduce since. I'd say check this patch in and if we can figure out STR the thumbnail progress circles we can open another bug. At least all the previews and thumbnails have circles.

I tried the change in comment 61 and when I restarted Minefield, there were no progress circles until I started to open and close tabs, and then they started to come back.

Comment on attachment 425746 [details] [diff] [review] Use the docshell of the <browser> Looks ok to me. I haven't been able to reproduce progress circle'd thumbnails, but I do get them on the live previews using the technique from comment 65; both for us and IE8. Totally SEP. :) As a side note for folks applying and testing this manually, make sure you delete XPC.mfl - your changes will have no effect otherwise.

would that be safe to push out in 3.6.2?

(In reply to comment #71) > (From update of attachment 425746 [details] [diff] [review]) > Looks ok to me. I haven't been able to reproduce progress circle'd thumbnails, > but I do get them on the live previews using the technique from comment 65; > both for us and IE8. Totally SEP. :) > > As a side note for folks applying and testing this manually, make sure you > delete XPC.mfl - your changes will have no effect otherwise. If we manually applied the patch, but wasn't aware of having to delete XPC.mfl, and now running a build with the formal patch, do we still need to delete the file ?

(In reply to comment #73) > would that be safe to push out in 3.6.2? This ought to be safe to push to 1.9.2 but just to be sure, I think it should sit on trunk for a few days.

Is anyone getting an increase in memory usage, or experiencing problems switching between tabs using the tab bar with this change in place? I seem to be getting large pauses when loading pages which include a flash element, and an accompanying increase in memory / CPU usage for that time too. And sometimes I can't switch between tabs using the tab bar (all mouse clicks ignored) until I select the tabs from the Windows task bar. This then "wakes up" the rest of the browser and reduces CPU / memory usage and generally returns everything to functional again. p.s. I've only really experienced this on one machine, so am willing to accept its a machine problem, but it's *not* a Flash issue as I've played with chnaging the version of the plugin.

(In reply to comment #76) > I seem to be getting large pauses when loading pages which include a flash > element, and an accompanying increase in memory / CPU usage for that time too. > And sometimes I can't switch between tabs using the tab bar (all mouse clicks > ignored) until I select the tabs from the Windows task bar. Supposing you're talking about Minefield (since you did not specify) your bug is most likely bug 543788, that is completely unrelated to this feature.

> > Supposing you're talking about Minefield (since you did not specify) your bug > is most likely bug 543788, that is completely unrelated to this feature. Yes, ok. I'll shut up and stop moaning. Please ignore me...

Comment on attachment 425746 [details] [diff] [review] Use the docshell of the <browser> Hard to know what to do with a branch approval request when the bug is marked "wontfix" for that branch. The patch looks fine, not sure whether the wontfix was simply "not worth the time" or "DO NOT WANT!"

(In reply to comment #79) > (From update of attachment 425746 [details] [diff] [review]) > Hard to know what to do with a branch approval request when the bug is marked > "wontfix" for that branch. The patch looks fine, not sure whether the wontfix > was simply "not worth the time" or "DO NOT WANT!" Just talked to Beltzner who said "go for it!" so I think it was the former.

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100317 Minefield/3.7a4pre Tabs: http://www.lenta.ru/news/2010/03/19/millennium/ http://www.warandpeace.ru/ http://www.warandpeace.ru/ru/news/view/45380/ http://www.warandpeace.ru/ru/news/view/45385/ http://www.warandpeace.ru/ru/news/view/45378/ http://www.warandpeace.ru/ru/news/view/45369/ http://www.warandpeace.ru/ru/news/view/45371/ http://www.warandpeace.ru/ru/news/view/45367/ http://www.warandpeace.ru/ru/news/view/45366/ http://www.warandpeace.ru/ru/news/view/45365/ http://www.warandpeace.ru/ru/news/view/45364/ Troubleshooting Information: Modified Preferences: accessibility.browsewithcaret = true browser.places.importBookmarksHTML = false browser.places.smartBookmarksVersion = 2 browser.startup.homepage = http://www.google.ru/firefox browser.startup.homepage_override.mstone = rv:1.9.3a4pre browser.tabs.warnOnOpen = false extensions.lastAppVersion = 3.7a4pre font.language.group = x-cyrillic network.cookie.cookieBehavior = 1 network.cookie.prefsMigrated = true places.history.expiration.transient_current_max_pages = 16098 privacy.cpd.siteSettings = true privacy.sanitize.migrateFx3Prefs = true privacy.sanitize.timeSpan = 0 Extensions none Plugins Mozilla Default Plug-in (File: npnul32.dll Version: 1.0.0.15) OS: Windows [Version 6.1.7600] (Ultimate) run on VMWare Player 3.01 Screen Resolution: 1440x900 px

(In reply to comment #81) > Created an attachment (id=433514) [details] > Aero Peek bug screen Not sure what your pointing out as I don't see progress circles, but it actually looks like your seeing bug 522506 - "generic" thumbnails _instead of_ progress circles or previews.

Comment on attachment 425746 [details] [diff] [review] Use the docshell of the <browser> a=LegNeato for 1.9.2.5. Please ONLY land this on mozilla-1.9.2 default, as we are still working on 1.9.2.4 on the relbranch