Last Comment Bug 608589 - When not getting the tab closing animation's transitionend event in a reasonable amount of time, forcefully remove the tab and report an error
: When not getting the tab closing animation's transitionend event in a reasona...
Status: VERIFIED FIXED
[softblocker][fx4-fixed-bugday]
:
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: -- normal with 16 votes (vote)
: Firefox 4.0b10
Assigned To: Dão Gottwald [:dao]
:
:
Mentors:
: 599723 612091 613241 626058 (view as bug list)
Depends on: 613888
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-31 02:57 PDT by Dão Gottwald [:dao]
Modified: 2014-01-24 08:18 PST (History)
83 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
betaN+


Attachments
screenshot (1.29 KB, image/png)
2010-10-31 02:58 PDT, Dão Gottwald [:dao]
no flags Details
handle gracefully (1.05 KB, patch)
2010-11-06 09:27 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
handle gracefully (checked in) (1.04 KB, patch)
2010-11-06 09:32 PDT, Dão Gottwald [:dao]
gavin.sharp: review+
Details | Diff | Splinter Review
Screenshot of assertion error. (31.53 KB, image/png)
2010-12-25 13:08 PST, Logan Rosen [:Logan]
no flags Details
yet another screenshot (7.03 KB, image/png)
2010-12-25 14:25 PST, Oleg
no flags Details
not sure that is right bug (15.94 KB, image/png)
2010-12-29 16:27 PST, Oleg
no flags Details
Another one. (24.50 KB, image/png)
2011-01-01 13:31 PST, Logan Rosen [:Logan]
no flags Details
Screenshot alert (11.17 KB, image/png)
2011-01-03 12:12 PST, Remy Mentasti
no flags Details
Another example (2011-01-07) (133.52 KB, image/png)
2011-01-07 22:30 PST, Zack Buhman
no flags Details
remove assertion dialog (1.31 KB, patch)
2011-01-12 15:47 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Splinter Review
avoid false positives (checked in) (815 bytes, patch)
2011-01-13 03:58 PST, Dão Gottwald [:dao]
gavin.sharp: review+
Details | Diff | Splinter Review
3-2-11 Assertion Failed Message (677.06 KB, image/png)
2011-03-02 14:33 PST, Chris B.
no flags Details

Description Dão Gottwald [:dao] 2010-10-31 02:57:34 PDT
+++ This bug was initially created as a clone of Bug #585785 +++

I just got a 1px wide tab again after trying to close it with Ctrl+w.
gBrowser._removingTabs still contains the tab and gBrowser._endRemoveTab(gBrowser._removingTabs[0]) succeeds when I call it manually, so it seems that the transitionend handler was never called for event.propertyName == "max-width".

Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101030 Firefox/4.0b8pre
Comment 1 Dão Gottwald [:dao] 2010-10-31 02:58:14 PDT
Created attachment 487225 [details]
screenshot
Comment 2 Dão Gottwald [:dao] 2010-11-06 09:27:06 PDT
Created attachment 488663 [details] [diff] [review]
handle gracefully

I'd like to land this to unblock bug 604735 and in case we don't find a proper fix for FF4.
Comment 3 Dão Gottwald [:dao] 2010-11-06 09:32:04 PDT
Created attachment 488665 [details] [diff] [review]
handle gracefully (checked in)

Switching to NS_ASSERT to make the failure obvious in nightlies... People don't look at the error console all the time.
Comment 4 Dão Gottwald [:dao] 2010-11-12 03:53:39 PST
*** Bug 599723 has been marked as a duplicate of this bug. ***
Comment 5 Dão Gottwald [:dao] 2010-11-14 00:38:41 PST
*** Bug 612091 has been marked as a duplicate of this bug. ***
Comment 6 Andreas Jung 2010-11-14 10:55:42 PST
Since Bug 585785 was fixed I rarely got ghost tabs, but sometimes I still get them.
Yesterday I noticed some strange behavior. I tried to close a tab, but a ghost tab stayed around. I didn't want to restart the browser to get rid of it, so I continued browsing. The ghost tab stayed around. Later when I clicked on the close button of the tab next to the ghost tab both tabs disappeared, the tab on whose close button I clicked and the ghost tab.
Is there a logical explanation for this behavior?
Comment 7 Dão Gottwald [:dao] 2010-11-20 06:16:45 PST
*** Bug 613241 has been marked as a duplicate of this bug. ***
Comment 8 Filip Zakrzewski 2010-11-24 02:23:49 PST
Maybe some pointer is sometimes set to wrong tab?
Comment 9 [not reading bugmail] 2010-11-24 17:40:32 PST
This happened again to me today on about:addons using tab's close button.
Comment 10 Stefan Ring 2010-11-25 09:24:40 PST
(In reply to comment #2, bug #608990)
> I frequently experience this as well. I'm using Firefox on Linux x86_64 (Fedora
> 13), built from Mercurial (Tag: FIREFOX_4_0b7_RELEASE).
> 
> I have not yet observed any predictable circumstances which cause this to
> happen, but I will try to have a look at the error console the next time this
> occurs.

Curiously, hasn't happened ever since, although I'm not aware of any change I've made to the configuration, and I use Firefox all day, every day.
Comment 11 :Ehsan Akhgari 2010-12-13 15:55:51 PST
Dao, I assigned this to you so that it doesn't show up in the list of unassigned blockers, because of the patch you had attached to the bug.  Is that patch not the right fix for this bug?
Comment 12 Dão Gottwald [:dao] 2010-12-13 17:34:36 PST
The patch does two things:
1) It allows this bug to be identified. As of bug 604735, tabs that failed to close are entirely invisible, so it's really hard to tell if this is still happening.
2) It fully removes closing tabs after a timeout. This is a workaround, not a proper fix.
Comment 13 Stefan Ring 2010-12-15 04:38:02 PST
I'm not sure if this is related, but I had a situation yesterday where the close buttons ("X") disappeared from all the tabs and reappeared after I opened another tab.

I will try to apply Dão's patch and use that for a while.
Comment 14 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-12-23 12:50:13 PST
Comment on attachment 488665 [details] [diff] [review]
handle gracefully (checked in)

I guess we can do this as a preventative measure, though it's rather gross. Was afraid of this having too much overhead for the close-many-tabs case, but we already clamp the number of concurrent animations, so that should be OK.
Comment 15 Dão Gottwald [:dao] 2010-12-23 15:37:07 PST
Comment on attachment 488665 [details] [diff] [review]
handle gracefully (checked in)

http://hg.mozilla.org/mozilla-central/rev/dba2dd6564d4
Comment 16 Johannes Pfrang [:johnp] 2010-12-24 08:25:14 PST
I just got this assertion and I really want to know if this assertion could also be fired on a slow computer, hanging cause of some other software running? 
I had my last ghost tab approximately 2 weeks ago and I would notice them regardless of bug 604735 landing, because I use TMP with "Select tab pointed for" set to 20ms. 
Or has it simply been a sort of "luck" to get a ghost tab just at the day of landing this attachement? 

OT: Is there a bug about tabs, reappearing some seconds after closing them shortly after starting to load a website? Couldn’t reproduce this on a clean profile, but it’s sometimes reproducible using my normal profile (->TMP issue?).
Comment 17 Wes Kocher (:KWierso) 2010-12-24 12:44:32 PST
Is the assertion supposed to show up in an alert box every time it fails?
Comment 18 Wes Kocher (:KWierso) 2010-12-24 12:57:58 PST
That is, popping up an alert/assert box on the failure seems less than "gracefully" handling it. Couldn't it just get logged to the console or something?
Comment 19 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-12-24 13:09:04 PST
The assert dialogs only appear in nightly/beta builds (release builds only print to the console). We want them to be noisy so that we know about the frequency and hopefully get some reliable STR...
Comment 20 Wes Kocher (:KWierso) 2010-12-24 13:14:22 PST
This seems to cause it to show the assertion one or more times in a row:
Set your homepage to something that takes a while to finish loading.
Middle-click the Home button to open it a lot of times in new tabs.
While the tabs are still loading, middle-click to close as many of the tabs as possible.
See the assertion, possibly more than once.
Comment 21 Logan Rosen [:Logan] 2010-12-25 13:08:32 PST
Created attachment 499733 [details]
Screenshot of assertion error.

Got this while browsing.
Comment 22 Oleg 2010-12-25 14:25:21 PST
Created attachment 499737 [details]
yet another screenshot
Comment 24 Chris B. 2010-12-26 08:46:19 PST
I got a different error message than what was previously posted and don't know what the last number after the comma in the error message signifies.

Site accessed = http://www.manhattanjobs.com/job.asp?id=29591129&aff=AC44BA2E-E3EB-4DBC-8BDB-9FCE01C58B09

Error Message = "ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)  Stack Trace: 0:([object XULElement],[object XULElement],0).

NOTE = My return value is "0".  Other screenshots show a return of "10" and "807".

This is confusing to me regarding why it would return "0" and still fail.  Usually a return value of "0" means the code completed without error.  For it to fail and return "0", maybe the code isn't allowed enough time to complete the task at hand (timeout error).
Comment 25 Dão Gottwald [:dao] 2010-12-26 10:47:36 PST
(In reply to comment #24)
> NOTE = My return value is "0".  Other screenshots show a return of "10" and
> "807".
> 
> This is confusing to me regarding why it would return "0" and still fail. 
> Usually a return value of "0" means the code completed without error.  For it
> to fail and return "0", maybe the code isn't allowed enough time to complete
> the task at hand (timeout error).

This isn't a return value but the setTimeout callback's last argument (the "lateness") as mentioned on <https://developer.mozilla.org/En/DOM/Window.setTimeout>.
Comment 26 Henrik Skupin (:whimboo) 2010-12-27 15:05:40 PST
I hit the same assertion today, but I'm not able to replicate it so far:

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],18)
Comment 27 Wes Kocher (:KWierso) 2010-12-27 18:57:23 PST
I'm hitting the assertion quite a bit today, but I'm also still seeing some unclosed closed tabs.
Comment 28 David Weir (satdav) 2010-12-28 08:33:47 PST
*** Bug 608580 has been marked as a duplicate of this bug. ***
Comment 29 David Tenser [:djst] 2010-12-29 03:37:52 PST
Got this problem today. STR:

1. Open a tab with this page http://english.gmarket.co.kr/challenge/neo_goods/goods.asp?goodscode=177499860 (heavy, long page in terms of number of pictures)
2. Open up some other tab (not sure if it matters which one)
3. Close that tab again (Firefox should try to switch back to the first tab again)
Comment 30 Oleg 2010-12-29 16:27:51 PST
Created attachment 500279 [details]
not sure that is right bug
Comment 31 AL 2010-12-29 22:44:48 PST
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],-5)

=====================================================
Ran into this bug for the first time today, after installing the most recent nightly. Not sure about the "-5" in the stack trace, can someone explain?
Comment 32 Dão Gottwald [:dao] 2010-12-30 03:07:22 PST
(In reply to comment #30)
> Created attachment 500279 [details]
> not sure that is right bug

Looks different to me. Did you get the "Giving up waiting for the tab closing animation to finish" alert?

(In reply to comment #31)
> Not sure about the "-5" in the stack trace, can someone explain?

See comment 25
Comment 33 Hannes Verschore [:h4writer] 2010-12-30 11:11:39 PST
Just got the alert:

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],-3)

I had 7-8 tabs open and was looking to a highres. .png file (http://files.jjcm.org/webp/bmw_webp.png). I was zoomed in. And when closing it I got that alert. I couldn't reproduce it. Using Minefield 4.0b9pre (2010-12-30)
Comment 34 Daniel Cater 2010-12-30 16:21:17 PST
I was seeing this bug at least once per day but I haven't seen the assertion since the checkin. Would the patch have made this less likely to happen at all?

And for the people who are seeing the assertion, is there any more useful information that could be added to it to help fix this bug?
Comment 35 AL 2010-12-30 22:45:16 PST
(In reply to comment #25)
> (In reply to comment #24)
> > NOTE = My return value is "0".  Other screenshots show a return of "10" and
> > "807".
> > 
> > This is confusing to me regarding why it would return "0" and still fail. 
> > Usually a return value of "0" means the code completed without error.  For it
> > to fail and return "0", maybe the code isn't allowed enough time to complete
> > the task at hand (timeout error).
> 
> This isn't a return value but the setTimeout callback's last argument (the
> "lateness") as mentioned on
> <https://developer.mozilla.org/En/DOM/Window.setTimeout>.

As in comment 31 and comment 33, the delay is sometimes negative. Why is this occurring? I checked the documentation at the link given above and I still don't see why the delay would come out negative.
Comment 36 Dão Gottwald [:dao] 2010-12-31 03:54:13 PST
(In reply to comment #34)
> I was seeing this bug at least once per day but I haven't seen the assertion
> since the checkin. Would the patch have made this less likely to happen at all?

No.

(In reply to comment #35)
> As in comment 31 and comment 33, the delay is sometimes negative. Why is this
> occurring? I checked the documentation at the link given above and I still
> don't see why the delay would come out negative.

The timer can fire early in order to prevent larger delays. E.g. -3 is better than +20.
Comment 37 ithinc 2010-12-31 06:24:02 PST
When I have the following rule, the assertion fails frequently.
.tabbrowser-tabs[dontresize] > .tabbrowser-tab:not([pinned]):not([faviconized]) {
  max-width: 150px !important;
  min-width: 150px !important;
}

When I remove one or both of ":not([pinned]):not([faviconized])", it works well. Strange!
Comment 38 ithinc 2010-12-31 06:36:27 PST
I have another rule in the mean time.

window[tabsontop] .tabbrowser-tab:not([pinned]):not([fadein]) {
  max-width: 0.1px !important;
  min-width: 0.1px !important;
}
Comment 39 Logan Rosen [:Logan] 2011-01-01 13:31:13 PST
Created attachment 500606 [details]
Another one.
Comment 40 patrickjdempsey 2011-01-01 14:03:42 PST
I'm seeing this alert every time I close a tab while running one of my themes.  I have the transition animations turned off:

.tabbrowser-tab,
.tabbrowser-tab > .tab-text,
.tabbrowser-tab > .tab-icon-image,
.tabbrowser-tab > .tab-close-button { 
-moz-transition: none!important;}

This alert probably shouldn't be appearing in the case that the transition animation has been turned off.  Or is there a better way to disable the transition?
Comment 41 Dão Gottwald [:dao] 2011-01-01 14:11:58 PST
(In reply to comment #40)
> This alert probably shouldn't be appearing in the case that the transition
> animation has been turned off.  Or is there a better way to disable the
> transition?

Yes, the browser.tabs.animate pref. Themes aren't supposed to mess with this.
Comment 42 patrickjdempsey 2011-01-02 15:45:04 PST
I just want to know how to avoid the error message, I don't need any lectures on what themes are or are not supposed to do.  Will "keeping" the transitions but setting the timer to 0 and having no state change avoid the error or still set it off?  Is there a minimum timer or action the error is looking for, or does it just go off if it does not detect the transition?
Comment 43 Dão Gottwald [:dao] 2011-01-02 15:51:10 PST
The error message is valid: you're actually preventing tabs from closing correctly with your code, which is also why I'll reiterate that themes aren't supposed to mess with this. You can reduce the transition duration, but nothing guarantees that by doing so you won't break something in the future.
Comment 44 patrickjdempsey 2011-01-02 16:39:11 PST
I understand that the error is valid in the case of an animation failing, but it seems like a pretty serious problem if setting a style to "none" causes part of the UI to fail.  Shouldn't -moz-transition:none have the same end effect as the config pref?  Perhaps the default theme should be modified with a note indicating the importance not disabling the animations with "none" since this error will eventually be buried?  No doubt other themers frustrated with these "extras" will attempt the same hack.
Comment 45 Remy Mentasti 2011-01-03 12:12:37 PST
Created attachment 500877 [details]
Screenshot alert
Comment 46 Remy Mentasti 2011-01-03 12:14:36 PST
I've just received this alert on the restart after update to 

Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110103 Firefox/4.0b9pre
Comment 47 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-01-05 06:07:07 PST
I've seen the alert few times when the system is under heavy load.
It is very annoying to show such error message to end user.
Comment 48 alex_mayorga 2011-01-05 10:01:45 PST
FWIW I just got this one on Mozilla/5.0 (Windows NT 6.0; rv:2.0b9pre) Gecko/20110105 Firefox/4.0b9pre ID:20110105030550 when closing an "App Tab".
Unable to replicate it, though.

"Error Message = "ASSERT: Giving up waiting for the tab closing animation to
finish (bug 608589)
Stack Trace:
0:([object XULElement],[object XULElement],0)."
Comment 49 Dão Gottwald [:dao] 2011-01-05 11:25:28 PST
(In reply to comment #47)
> I've seen the alert few times when the system is under heavy load.

These might be false positive, we should probably raise the timeout.

> It is very annoying to show such error message to end user.

We're not going to show it to end users.
Comment 50 Daniel Buchner [:dbuc] 2011-01-06 12:58:50 PST
Just reporting an instance of the error being raised in the wild on Fx 4b9pre 2011-01-05. I wasn't sure if you all wanted to hear about these occurrences?

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],164)
Comment 51 Nicholas Nethercote [:njn] 2011-01-06 14:50:42 PST
I just hit this, my assertion looked like the one in comment 50.  Interestingly, I was running the browser under Valgrind at the time -- Valgrind makes the browser run 20x or more slower.  That might be an interesting data point.
Comment 52 Shane Bundy 2011-01-06 16:59:08 PST
Got it for the first time on overclocker.net:

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],4)
Comment 53 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-01-07 14:17:36 PST
Hit this today with a different number, so reporting it in case it's relevant.

Stack Trace: 
0:([object XULElement],[object XULElement],1413)
Comment 54 Henrik Skupin (:whimboo) 2011-01-07 18:51:14 PST
Dao, I have a profile where I can always reproduce this assertion. I can send it to you if you want. But I'm not sure if it will also work on Windows.

Possible requirements:
* Have a lot of tabs open
* Have another theme installed (in my case it is Walnut)
* Select one of the open tabs
* Hold down Cmd+W to close a bunch of tabs in a row

After I release the keys, it will take a little moment but then I always see the assert message.
Comment 55 Zack Buhman 2011-01-07 22:30:14 PST
Created attachment 502202 [details]
Another example (2011-01-07)
Comment 56 Dão Gottwald [:dao] 2011-01-07 23:50:42 PST
(In reply to comment #54)
> Dao, I have a profile where I can always reproduce this assertion. I can send
> it to you if you want. But I'm not sure if it will also work on Windows.
> 
> Possible requirements:
> * Have a lot of tabs open
> * Have another theme installed (in my case it is Walnut)
> * Select one of the open tabs
> * Hold down Cmd+W to close a bunch of tabs in a row
> 
> After I release the keys, it will take a little moment but then I always see
> the assert message.

This might just be a bug in the Walnut theme, see comment 40 ff.
Comment 57 Henrik Skupin (:whimboo) 2011-01-08 01:56:17 PST
(In reply to comment #56)
> This might just be a bug in the Walnut theme, see comment 40 ff.

It does not happen all the time when I close a tab, only by holding down the keys and closing a bunch of tabs in one step. Also it doesn't seem to happen for new windows. I will keep this profile frozen until it is clear if it's helpful.
Comment 58 Tom Levels 2011-01-10 06:45:41 PST
I just encountered this bug for the first time, using latest nightly, default theme (I got the assert message).
Comment 59 christian 2011-01-10 20:04:48 PST
(In reply to comment #54)
> Dao, I have a profile where I can always reproduce this assertion. I can send
> it to you if you want. But I'm not sure if it will also work on Windows.
> 
> Possible requirements:
> * Have a lot of tabs open
> * Have another theme installed (in my case it is Walnut)
> * Select one of the open tabs
> * Hold down Cmd+W to close a bunch of tabs in a row
> 
> After I release the keys, it will take a little moment but then I always see
> the assert message.

I see the same thing, can reproduce 100% on Mac, and have no themes installed:

1 - Open a new window
2 - Hold down cmd-T for > 10 seconds (mine is opening blank tabs)
3 - Hold down cmd-W 
4 - Get assertions at some point
Comment 60 IU 2011-01-10 20:41:03 PST
I can confirm comment 59 on Windows XP.
Comment 61 Daniel Cater 2011-01-11 03:35:53 PST
(In reply to comment #60)
> I can confirm comment 59 on Windows XP.

Is the CPU maxed out during this? It could be that the high load caused by closing so many tabs quickly just causes a delay which triggers the 2-second timeout in this patch (and eventually the tabs would have closed on their own). Keyboard shortcuts like Ctrl+T and Ctrl+W seem to work off of the keyboard repeat rate and the UI can lag behind the queue of simulated keypresses (not stopping when the keys are released).

Hopefully this will be fixed by the patch in bug 613888.
Comment 62 Siddhartha Dugar [:sdrocking] 2011-01-11 04:18:18 PST
Tab animation(browser.tabs.animate) should be disabled until this bug is fixed. It feels really annoying.
Comment 63 Raul Malea 2011-01-11 06:36:47 PST
Confirm this bug: ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],0)

Windows 7 32bit

My Minefield: Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110110 Firefox/4.0b9pre ID:20110110160729

In this link: http://denisuca.com/numai-pe-yahoo-messenger.html

about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/f9f48079910f
Build platform
target
i686-pc-mingw32
Build tools
Compiler 	Version 	Compiler flags
d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl 	14.00.50727.762 	-TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl 	14.00.50727.762 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1
Configure arguments

--enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-tests
Comment 64 Daniel Buchner [:dbuc] 2011-01-11 06:52:24 PST
A bunch of these reports are citing multi-tab closing scenarios as one of the conditions for raising the assertion. I just wanted to make sure to let the bug owner know that I have never seen this action occur as a result of a multi-tab close, for me it happens randomly when I close a single tab now and then (maybe once a day).

Windows 7, Minefield
Comment 65 Virtual_ManPL [:Virtual] - (ni? me) 2011-01-11 08:08:01 PST
(In reply to comment #59)
> 1 - Open a new window
> 2 - Hold down cmd-T for > 10 seconds (mine is opening blank tabs)
> 3 - Hold down cmd-W 
> 4 - Get assertions at some point

Good method to reproduce this bug, also get this too on XP 32bit and 7 64bit with both 32 & 64bit versions of Firefox
Comment 66 Phil Randal 2011-01-11 08:53:12 PST
I have never seen this bug with 4.0b8, but am getting it repeatedly with 4.0b9 build1 on Windows XP

Ctrl-T to open tab, click in new tab, close it, and boom

0:([object XULElement],[object XULElement],1)
Comment 67 Henrik Skupin (:whimboo) 2011-01-11 09:23:16 PST
Who will/can own this blocker? I'm not sure what else is needed from QA side to get further progress. We have posted a lot of feedback on the raised assert messages during the last days.
Comment 68 Chris B. 2011-01-11 10:03:09 PST
Could this be caused by an out of memory issue?

The test stated in comment 65 is VERY stressful to the CPU and Minefield and no
one would EVER have over two hundred windows / tabs open at once.

I have 4 GB of memory, so I TRIPLED the times stated in comment 65 and
eventually received error:
0:([object XULElement],[object XULElement],2648).

When the above error appeared, all the hundreds of blank tabs that were open
disappeared and there was just one empty tab with the error dialog.

I am using Minefield 32-Bit (Build 1/11/11) under Windows 7 64-Bit Home
Premium.
Comment 69 Henrik Skupin (:whimboo) 2011-01-11 10:05:10 PST
Also how is hardware acceleration involved here? Does it more often happen with enabled h/w acceleration?
Comment 70 Daniel Buchner [:dbuc] 2011-01-11 10:22:49 PST
@Chris B

Not sure about it being strictly due to running out of memory. I have about 8 or 9 active tabs and, as I stated above, this occurs for me at random times when closing just a single tab.
Comment 71 IU 2011-01-11 10:42:35 PST
(In reply to comment #68)
> Could this be caused by an out of memory issue?
 
I very seriously doubt it.  I have 4 GB and can reproduce with much less than 5 windows, much less than 50 tabs, and Firefox consuming not much more than 200 MB or RAM.
Comment 72 Chris B. 2011-01-11 10:48:40 PST
(In reply to comment #71)
> (In reply to comment #68)
> > Could this be caused by an out of memory issue?
> 
> I very seriously doubt it.  I have 4 GB and can reproduce with much less than 5
> windows, much less than 50 tabs, and Firefox consuming not much more than 200
> MB or RAM.

I didn't think so either, but I'm just trying to help get this bug resolved by exploring all options.
Comment 73 nonoitall 2011-01-11 14:45:54 PST
(In reply to comment #66)
> I have never seen this bug with 4.0b8, but am getting it repeatedly with 4.0b9
> build1 on Windows XP

The bug was present in b8 (and many betas before that).  However, up until beta 9, no error message was produced, nor would the tab in question finally be closed when the browser gave up on waiting for it to close 'the right way'.  You would instead wind up with a phantom tab that was either very skinny or completely invisible and that was impossible to close without restarting the browser.

B9 provides a workaround for this issue by forcing the tab to close after a timeout, and it also produces the assertion so that people know when the bug is happening.
Comment 74 Phil Randal 2011-01-11 15:03:32 PST
The popup notification really needs to vanish before beta9's public release
Comment 75 nonoitall 2011-01-11 15:37:10 PST
If they can solve the underlying bug, I'd agree.  If they can't though, it seems counterproductive to hide the bug from the beta testers who are supposed to be reporting it.
Comment 76 Phil Randal 2011-01-11 16:00:35 PST
People will just turn off animated tabs or revert rather than put up with the annoyance of that popup, though, alas
Comment 77 Daniel Buchner [:dbuc] 2011-01-11 16:17:51 PST
What about logging the error in a different way, say the nsIAlertsService for instance? If you did that it wouldn't affect the user's flow hardly as much as a blocking alert.
Comment 78 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-01-12 15:33:34 PST
We should disable the assert dialog, it's not particularly useful because it seems to catch a lot of false positives related to timeout lag (I think that's what most of the "close many tabs quickly" reports are, as comment 61 suggests). Bug 613888 likely covers the only real underlying bug here.
Comment 79 Dão Gottwald [:dao] 2011-01-12 15:40:34 PST
(In reply to comment #78)
> Bug 613888 likely covers the only real underlying bug here.

It's currently not clear to me that bug 613888 will fix this. Did you gather this from reading the comments or the patch?

Btw, I haven't seen the dialog once. But I can look if I can trigger a false positive and make the code separate these cases out.
Comment 80 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-01-12 15:47:29 PST
Created attachment 503324 [details] [diff] [review]
remove assertion dialog

We could also just wait for bug 613888 (which should be fixed soon) and then just remove this entirely.
Comment 81 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-01-12 15:49:35 PST
Oh sorry, didn't see your latest comment. The comment in attachment 502248 [details] [diff] [review] describes what sounds like a general issue that could be the cause of this bug.
Comment 82 Dão Gottwald [:dao] 2011-01-12 15:51:25 PST
It will be extremely hard to verify that this doesn't happen anymore with the dialog removed. I'll look into detecting the false positives first.
Comment 83 Dão Gottwald [:dao] 2011-01-13 03:58:54 PST
Created attachment 503457 [details] [diff] [review]
avoid false positives (checked in)

I had a hard time triggering this, but when it happened, the computed max width was 250px...
Comment 84 Ezra Schoonover 2011-01-13 07:11:51 PST
I can reproduce this bug easily.  With some pinned tabs and multiple un-pinned tabs open, middle-click to close one of the tabs (except, I think, the left-most or right-most un-pinned tab).  ***here is the crucial part***   QUICKLY move your cursor down into the content area (vbox#appcontent > tabbrowser#content > ...etc, etc... browser > #document).

You should notice that as the tabs slide in to the empty space of the recently closed tab, the gap between is a bit too wide (for a split second).  As the margin/padding collapses, the error occurs and the alert appears.

-TinMan (a.k.a. Ezra)

p.s.
This is still happening in the latest beta10pre

p.p.s.
I only seem to get zeros or positive integers in my error messages.. never negative integers
0:([object XULElement],[object XULElement],0)
Comment 85 Dão Gottwald [:dao] 2011-01-14 02:48:57 PST
Comment on attachment 503457 [details] [diff] [review]
avoid false positives (checked in)

http://hg.mozilla.org/mozilla-central/rev/f24f049857a5
Comment 86 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2011-01-14 23:27:32 PST
Bug 613888 landed today, so if it was the cause of this bug, this might improve starting in tomorrow's mozilla-central nightlies.
Comment 87 Abdoulah 2011-01-15 06:54:38 PST
*** Bug 626058 has been marked as a duplicate of this bug. ***
Comment 88 Abdoulah 2011-01-15 06:57:19 PST
This message just popped out minutes ago after closing a tab.

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],0)
Comment 89 Phil Randal 2011-01-17 05:28:00 PST
I've been unable to reproduce this with limited testing with the latest nightly on Windows.

Looking good so far.
Comment 90 Kuno Meyer 2011-01-17 12:36:22 PST
FF4b9. Just got a message box mentioning to this bug when (supposedly) trying to close a tab displaying [1]. Tab stayed open, second attempt to close it succeeded.

Cannot reproduce the behavior, though.

[1] http://books.google.ch/books?id=IcuCs5gKhcIC&pg=PA155&lpg=PA155&dq=signifikanztest+%FCberbuchung&source=bl&ots=IupOa8qRXC&sig=ZT8kHwwiRKfKET303w8mtvmDUXQ&hl=de&ei=t6Q0TejGFciEOs-4nLUC&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBcQ6AEwAA#v=onepage&q&f=false
Comment 91 Sergey «Mithgol the Webmaster» Sokoloff 2011-01-17 21:40:40 PST
Just gor a message box with assert mentioning this bug when I closed two tabs one after another.

Not reproduced after I reopened these tabs by Tab Mix Plus and closed them again.
Comment 92 Ed Avis 2011-01-18 06:10:04 PST
I saw a assertion failure message similar to that in comment 88, but with slightly different stack trace.  This was when repeatedly hitting C-F4 to close a large number of open tabs.

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace:
0:([object XULElement],[object XULElement],-5)

Curiously, searching Bugzilla for the first line of the error message returns no hits.
Comment 93 Ed Avis 2011-01-18 06:10:41 PST
I forgot to add: Firefox 4.0b9 on Windows XP.
Comment 94 Henrik Skupin (:whimboo) 2011-01-19 10:06:26 PST
*** Bug 592232 has been marked as a duplicate of this bug. ***
Comment 95 Stephen 2011-01-21 13:00:39 PST
This is common for me, Firefox 4.0b9, and was common in firefox 4.0b8, but at least there's a warning that kills the tab after a timeout. in 4.0b8, the ghost tab just hung on until the whole browser was closed, and was still considered a tab. When the bug is experienced, there is no strain on RAM or space at all, only using 300 MB of 3 GB.

Firefox 4.0b9
Arch Linux Kernel: 2.6.37-ARCH
1.8 Ghz Dual Core Intel i686 processor
Comment 96 Xleon 2011-01-22 07:43:04 PST
I'm seeing this alert every time I close a tab while running one of my themes. 
I have the transition animations turned off:

.tabbrowser-tab,
.tabbrowser-tab > .tab-text,
.tabbrowser-tab > .tab-icon-image,
.tabbrowser-tab > .tab-close-button { 
-moz-transition: none!important;}

This alert probably shouldn't be appearing in the case that the transition
animation has been turned off.  Or is there a better way to disable the
transition?

------------

On similar note, I have been wanting to disable animated tab transitions only on the closing of a tab. Which the above css code partly works in doing..if someone could please let me know what css selector is required to only have -moz-transition: none! work only on the closing of tab, and not the opening of a new tab, that would be great.

Of course I want to leave animated.tabs config entry to default true (such that the opening of a new tab animates as normal) however the above code "-moz-transition: none" does generate this error "Giving up waiting for the tab closing animation to finish "  everyone else is reporting when I close tabs in quick succession, its like it is still waiting the close animation delay, and throws up the error if you try get to close the next tab to quickly.

Sidenote, without the above css applied, and animated.tabs [true or false]... I cannot get the error to appear at all including using method:

1 - Open a new window
2 - Hold down cmd-T for > 10 seconds (mine is opening blank tabs)
3 - Hold down cmd-W 
4 - Get assertions at some point
Comment 97 patrickjdempsey 2011-01-22 13:15:24 PST
Instead of using -moz-transition: none which causes the error just reduce the delay down to 0.  You can find the transition code in browser.css in the /content/ section of the default theme.  MozillaZine or another forum is a more appropriate place to ask than Bugzilla.
Comment 98 Xleon 2011-01-22 14:39:46 PST
MozillaZine is unfortunately moderated by what I can only guess are grudge bearing gestapo censorship cretins. You get banned for merely having firefox related discussions that don't fit in line with the consensus.

So that wasn't an option, actually a bit of shame its the only other place for firefox discussion, as the moderators there only know how to derail topics onto other irrelevant user topic discussions.

Anyway I did actually find relevant transition and selector code, the closing bug as reported here isn't an issue, though some other css transition quirks have cropped up.
Comment 99 Lexi Robinson 2011-01-24 09:18:26 PST
Hi, I'm getting the assert and the FF channel said to post this here.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
I've got 8 app tabs open, and had a single normal tab with iGoogle on it. No custom themes or animation adjustments. The only active program was Steam, which wasn't doing anything much.
I middle clicked on a couple of pages from my iGoogle bookmarks list, and briefly glanced at them, before closing each tab with middle click. One of them did not load, or give the appearance of loading. It was a white page, with the url in the tab's title section, and a white page icon. I middle clicked on it.
After a while, this popped up.
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589) 
Stack Trace: 
0:([object XULElement],[object XULElement],26)
Hope that helps.
Comment 100 Stefan Plewako [:stef] 2011-01-25 00:25:00 PST
Just got this assertion:
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],2)

(fx4.0b9, mac, few tabs and not much load on relatively new mbp)
Comment 101 u142003 2011-01-25 15:00:13 PST
It has happened twice today for me (same message as Stefan Plewako) but never before. And like him I run beta 9 on Mac OS X.
Comment 102 Phil Randal 2011-01-25 15:26:16 PST
Can people reporting problems in 4.0b9 please verify it is fixed in 4.9b10, which has just been released.

Works for me in 4.0b10.
Comment 103 Kendall Cotton 2011-01-25 17:36:58 PST
I have had a ghost tab problem since fx4.0b3, when I downloaded the beta, the first three tabs I close I get a ghost tabs for each, then no ghost tab when i close a tab. I can close them from  panorama and I don't get a ghost tab. In fx4.0b9 I would get "ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)..." box, click OK and there tab would  be no ghost tab. In fx4.0b10 I get the same thing as before beta 9. So the box is gone but I still have a tab problem. I'm on W7 x64, and have tried different themes but doesn't change anything. Hope this helps.
Comment 104 Kuno Meyer 2011-01-26 11:08:31 PST
Just updated to FF4b10 on Windows Vista. 

I still can reproduce the error message following the instructions in comment 59. However, it takes me now at least 5 attempts to get the error just once, whereas with FF4b9 I got it right at the first time.

I was able to reproduce the error twice. In both cases, I opened tabs for at least 15 seconds and I had to wait until all the tabs but the remaining last one were closed before the error message appeared. In addition, in both cases I continued to press Ctrl-W after reaching a tab count of 1. In the background I had a second Firefox window open with another two tabs.
Comment 105 tabmix.onemen 2011-02-01 01:19:27 PST
According to CSS transitions documentation:
The "transitionend" event doesn't fire if the transition is aborted because the animating property's value is changed before the transition is completed

Is it possible that extension theme or Firefox code itself change one of the transition property's - min-width, max-width, opacity.

we can add DOMAttrModified eventListener in gBrowser.removeTab and catch changes to these property's that occur for tabs that are in this._removingTabs
Comment 106 Dão Gottwald [:dao] 2011-02-01 01:24:01 PST
(In reply to comment #105)
> Is it possible that extension theme or Firefox code itself change one of the
> transition property's - min-width, max-width, opacity.

Only the max-width is relevant here, and no, Firefox code doesn't change that. An extension could, of course.

> we can add DOMAttrModified eventListener in gBrowser.removeTab and catch
> changes to these property's that occur for tabs that are in this._removingTabs

Adding a DOMAttrModified listener once slows down all further DOM mutations in that window, so we can't do that.
Comment 107 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-02-01 05:36:40 PST
(In reply to comment #105)
> we can add DOMAttrModified eventListener in gBrowser.removeTab and catch
> changes to these property's that occur for tabs that are in this._removingTabs

This is off topic, and better to not continue this discussion in this bug:
Using mutation event listeners slows down significantly all 
the DOM mutations in the document. This happens in all the browsers.
So if just possible, do not ever use them. Mutation events are already
deprecated in DOM 3 Events, and a replacement for them will be implemented soon.
For more information, look at W3C WebApps WG mailing list archives.
Comment 108 Dietrich Ayala (:dietrich) 2011-02-01 06:30:46 PST
is the timeout workaround from comment #12 still in place? if so, i'm not sure we need to block on this.

from the comments, it sounds like for Fx4 we need to decide whether the problem even with the workaround is bad enough that we turn off tab animation by default, or that we can ship the workaround, or we rewrite tab animations without CSS transitions.

any other options?
Comment 109 Dão Gottwald [:dao] 2011-02-01 07:49:02 PST
I expect that bug 613888 fixed this.

> is the timeout workaround from comment #12 still in place?

Yes, and I'd like it to stay for now just to be on the safe side and to guard against misbehaving extensions and themes.
Comment 110 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-02-01 07:58:21 PST
But the assert will be removed or disabled before FF4 is released, right?
Comment 111 Dão Gottwald [:dao] 2011-02-01 08:02:51 PST
It won't show up in release builds. NS_ASSERT takes care of that.
Comment 112 patrickjdempsey 2011-02-01 16:29:34 PST
(In reply to comment #106)
> (In reply to comment #105)
> > Is it possible that extension theme or Firefox code itself change one of the
> > transition property's - min-width, max-width, opacity.
> 
> Only the max-width is relevant here, and no, Firefox code doesn't change that.
> An extension could, of course.

Also remember that because of removing the config settings browser.tabs.tabMaxWidth and browser.tabs.tabMinWidth, there will be MANY users using userChrome.css (as suggested by Mozilla) to adjust the tab-width values.  When I tried changing tab-width (smaller or larger than default, doesn't matter) in userChrome.css I didn't get *true* ghost tabs (or the error) but I did get a large blank space.
Comment 113 Dão Gottwald [:dao] 2011-02-02 12:48:34 PST
(In reply to comment #112)
> (In reply to comment #106)
> > (In reply to comment #105)
> > > Is it possible that extension theme or Firefox code itself change one of the
> > > transition property's - min-width, max-width, opacity.
> > 
> > Only the max-width is relevant here, and no, Firefox code doesn't change that.
> > An extension could, of course.
> 
> Also remember that because of removing the config settings
> browser.tabs.tabMaxWidth and browser.tabs.tabMinWidth, there will be MANY users
> using userChrome.css (as suggested by Mozilla) to adjust the tab-width values. 
> When I tried changing tab-width (smaller or larger than default, doesn't
> matter) in userChrome.css I didn't get *true* ghost tabs (or the error) but I
> did get a large blank space.

You need to set it with the right attributes on .tabbrowser-tab, or use the add-on that will do that for you. https://addons.mozilla.org/en-US/firefox/addon/custom-tab-width/
Comment 114 Alexey Perepyolkin [:chaos] 2011-02-04 11:47:42 PST
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Comment 115 David Tenser [:djst] 2011-02-17 15:41:58 PST
Just found a fairly reliable way of making the extreme delay after closing a tab to happen, but I don't get any error message anymore (and didn't realize this bug was fixed). Still, the delay is pretty horrible on heavy pages and completely locks up the Minefield UI for seconds on this relatively fast computer.

Should I file a new bug for that, or is there already one filed? I'd like to post some STRs.
Comment 116 Shane Bundy 2011-02-17 23:07:30 PST
I think a new bug should be filed as this one is only for the transitionend event on tabs. I also get lock ups on heavy pages so I don't see a reason why not.
Comment 117 Chris B. 2011-03-02 14:32:27 PST
I know this bug is closed and "VERIFIED FIXED", but I just got an "Assertion Failed" message today and cannot go to any tabs.  In the provided screenshot, the Minefield window is in the upper left and Internet Explorer is in the bottom half of the screen.
Comment 118 Chris B. 2011-03-02 14:33:52 PST
Created attachment 516414 [details]
3-2-11 Assertion Failed Message
Comment 119 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2011-03-03 02:06:58 PST
(In reply to comment #111)
> It won't show up in release builds. NS_ASSERT takes care of that.

What flag disables NS_ASSERT?
Comment 120 :Ehsan Akhgari 2011-03-03 12:04:02 PST
(In reply to comment #119)
> (In reply to comment #111)
> > It won't show up in release builds. NS_ASSERT takes care of that.
> 
> What flag disables NS_ASSERT?

It uses the app.update.channel pref to determine if were in a release build: <http://mxr.mozilla.org/mozilla-central/source/toolkit/content/debug.js#70>.  Here, "release" doesn't mean "non-debug", it literally means a released version.
Comment 121 Sam "SammyTheSnake" Penny 2011-07-05 04:17:26 PDT
I don't know if what I have to say is actually helpful, but I'm on debian using iceweasel based on firefox 5.0 (iceweasel 5.0-1) and I had a phantom tab that I could access using Ctrl-Tab (or Shift-...) but which did not appear on the tab bar at the top of my window. After being amused for a moment, I closed the tab using Ctrl-W, then re-opened it using Shift-Ctrl-T and got a dialog box with the following message (which led me here)

"""
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],68)
"""

I hope this is useful but if not, thanks for firefox! :-)

Cheers & God bless
Sam "SammyTheSnake" Penny
Comment 122 Filip Zakrzewski 2011-07-05 06:07:20 PDT
I had that issue too
It seems that this bug isn't fixed
Comment 123 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-07-05 12:26:32 PDT
Sammy, Hawan - Phantom tabs sounds like something I'm seeing, but is a different issue. There should be an assert there because there is no tab. I filed bug 669417 for that.
Comment 124 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-08-08 07:52:02 PDT
I just saw the assert mentioned in comment 121, too in current trunk build.
I think it was related to closing the about:addons tab, not sure.
But I had also these css rules in my userChrome.css file at that time:
.tabbrowser-tabs[drag=detach] > .tabbrowser-tab[dragged]:not(:only-child) {
 -moz-transition: max-width 0ms ease-out !important;
}
.tabbrowser-tabs[drag=move] > .tabbrowser-tab[fadein]:not([dragged]) {
 -moz-transition: -moz-transform 0ms ease-out !important;
}
.tabbrowser-tabs[drag=finish] > .tabbrowser-tab[dragged][fadein] {
 -moz-transition: -moz-transform 0ms ease-out !important;
}
Comment 125 Emanuel Hoogeveen [:ehoogeveen] 2011-08-09 04:14:12 PDT
I just got this assertion after closing a tab that contained a private message on board.byuu.org, saying

"ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],1)"

Profile is practically new, extensions are ABP 1.3.10a.3096 (a nightly, though I doubt that's relevant here), Personal Menu 5.0.5 and Stylish 1.2.

Testest on latest trunk, 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110808 Firefox/8.0a1
built from http://hg.mozilla.org/mozilla-central/rev/f414db34c70b
Comment 126 Andrew McCreight [:mccr8] 2011-08-28 20:37:29 PDT
I got this assertion just now in a Nightly build, after closing http://dmv.ca.gov/pubs/interactive/tdrive/exam.htm while watching a Hulu video.  Couldn't reproduce.  I didn't notice anything wrong aside from the dialog I had to close.
Comment 127 B.J. Herbison 2011-09-29 07:26:17 PDT
I received the assertion today with the 29 September Nightly on Windows XP. Before the assertion I knew something was wrong -- my tab looked like the mouth of a six-year old with gaps from missing teeth. A couple of times today I've seen gaps in the tab bar (about the size of a tab) and several times I've noticed tabs overlapping each other.
Comment 128 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-29 07:50:16 PDT
Can someone please try to reproduce this with a brand new profile, no add-ons installed whatsoever? Comment 121 through 127 all refer to the same issue (which is not necessarily the issue reported in this bug -- see bug 669417 which was resolved DUPE as an add-on issue).
Comment 129 B.J. Herbison 2011-09-29 08:12:50 PDT
If I see the situation again I will try to find a way to reproduce it. I've only seen it this once.

But for the record, the behavior I saw does not match the issue described in bug 669417 and does not match the picture from bug 672780. Instead of seeing

tab1 tab2 tab3 tab4 tab5

I saw something like

tab1 tab2 blank tab3 tatab5

I didn't check for missing tabs, but the display was gonzo. I'm sorry now I didn't take a screen shot but I was focused on completing a task for my paying job, and by the time that task was done the tab bar was back to normal.
Comment 130 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-29 08:52:06 PDT
@BJ, when this happens again, can you please file a new bug for it as a follow up to this bug? Your issue sounds different than the problem which was solved by this bug.
Comment 131 Mathieu Marquer 2011-10-18 02:12:19 PDT
Just got this bug pop-up as well after closing a tab.
Comment 132 Theliel 2011-10-18 05:02:54 PDT
I can confirm too. In my case, popup appear once a "phantom" blank tab are closed. After a Session restore, some tabs are opened in "blank" instead webpages, and some others tabs are created in blank but arent show in bar, only on list tabs. Please, see the image:

http://img444.imageshack.us/img444/6608/errorsw.png
Comment 133 Jeff Muizelaar [:jrmuizel] 2011-10-25 06:36:22 PDT
I also just got this message:
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],-2)
Comment 134 Marco Castelluccio [:marco] 2011-12-08 06:26:46 PST
While using Firefox 9 Beta 5:
ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement],151)

And a lot of times (when I've many tabs opened) the tab closing animation is really really slow.
This is a regression, because with Firefox 8 and with older betas of Firefox 9, this issue never happened.
Comment 135 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-08 09:37:14 PST
As requested in comment 130, please file a new bug. Thanks.
Comment 136 Mike Hommey [:glandium] 2011-12-23 10:10:52 PST
Did anyone file a bug for the ASSERT: Giving up waiting for the tab closing animation to finish message? I didn't find one, and I'm getting this a lot on aurora.
Comment 137 Dão Gottwald [:dao] 2011-12-23 11:53:24 PST
(In reply to Mike Hommey [:glandium] from comment #136)
> Did anyone file a bug for the ASSERT: Giving up waiting for the tab closing
> animation to finish message? I didn't find one, and I'm getting this a lot
> on aurora.

Please file a bug if you can reproduce it in a new profile.
Comment 138 Marco Castelluccio [:marco] 2011-12-23 14:01:52 PST
Mike, I've filed bug 708912 (I've reproduced it in a new profile).
Comment 139 Rodrigo Navarrete 2012-01-31 00:42:00 PST
Hello, I'm new to reporting bugs at bugzilla but just wanted to comment I'm using Firefox 10 Beta 6 at the moment and just got this bug. I selected a tab from the list of tabs and it displayed the page but not the tab itself in the bar. I had a lot of tabs open (30 to be exact), could be that the reason?

I got this message in an alert box after closing it with Ctrl+W:

"ALERT: Giving up waiting for the tab closing animation to finish (bug 608589)"
Comment 140 Dão Gottwald [:dao] 2012-01-31 01:12:41 PST
(In reply to Rodrigo Navarrete from comment #139)
> I selected a
> tab from the list of tabs and it displayed the page but not the tab itself
> in the bar. I had a lot of tabs open (30 to be exact), could be that the
> reason?

Chances are that some add-on messed this up. That, or you discovered some deeply buried Firefox bug. Do you use any tab related add-ons?
Comment 141 Filip Zakrzewski 2012-01-31 01:29:27 PST
Hmm,
tried to open/close a lot of with empty tabs - nothing wrong is happening

Maybe this is related to time that is required to manage memory? (like releasing it while closing tab)

This might happen with flash/java on the tabs - then Firefox might do it slower than predicted :(
Comment 142 Rodrigo Navarrete 2012-01-31 08:30:49 PST
(In reply to Dão Gottwald [:dao] from comment #140)
> (In reply to Rodrigo Navarrete from comment #139)
> > I selected a
> > tab from the list of tabs and it displayed the page but not the tab itself
> > in the bar. I had a lot of tabs open (30 to be exact), could be that the
> > reason?
> 
> Chances are that some add-on messed this up. That, or you discovered some
> deeply buried Firefox bug. Do you use any tab related add-ons?

No, I don't have any tabs add on. I also noticed that I couldn't write text or select the text areas with the cursor in a forum I had open in a tab (like the one I'm using to add comments here). That happened moments before the error with the tabs poped up. After closing the faulty tab with Ctrl+W I could enter text again.
Comment 143 dc 2013-02-02 14:00:25 PST
FF21a1
Comment 144 alex_mayorga 2013-05-16 14:16:47 PDT
FWIW I saw the following prompt appear once on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:24.0) Gecko/20130515 Firefox/24.0 ID:20130515141643 CSet: b30552dbb013 

"ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589) Stack Trace: 0:([object XULElement],[object XULElement])
<OK>"

Is this a the same bug I'm seeing?
Comment 145 Anshu Prateek 2013-07-03 21:22:16 PDT
I got this now too. Time to reopen the bug?
Comment 146 Anshu Prateek 2013-07-03 21:23:13 PDT
Or rather need to remove the assertion alert since the tab closed..
Comment 147 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-07-04 10:05:21 PDT
This was fixed a long time ago. If it's come back then you need to file a new bug report.
Comment 148 timeless 2013-08-13 14:31:31 PDT
ashughes: i hit this dialog w/ yesterday's Nightly -- if you don't want people commenting on this bug, then the code that tosses up the error really needs to say something other than:

ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589)
Stack Trace: 
0:([object XULElement],[object XULElement])
Comment 149 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-13 14:55:22 PDT
(In reply to timeless from comment #148)
> ashughes: i hit this dialog w/ yesterday's Nightly -- if you don't want
> people commenting on this bug, then the code that tosses up the error really
> needs to say something other than:

Feel free to file a new bug. If it's happening then there's likely a new regression which should be investigated. Adding more comments to this bug will get us no closer to resolving this for you.
Comment 150 Michael Lefevre 2013-08-13 15:18:13 PDT
There are already other open bugs that refer to the message...

I wonder if it would be worth filing a bug on changing (or removing) the assertion message so that the product doesn't claim this bug is happening, when it isn't?
Comment 151 Antoine Turmel [:GeekShadow] 2014-01-23 18:25:34 PST
(In reply to Michael Lefevre from comment #150)
> There are already other open bugs that refer to the message...
> 
> I wonder if it would be worth filing a bug on changing (or removing) the
> assertion message so that the product doesn't claim this bug is happening,
> when it isn't?

I still have this message sometimes (Firefox 27 Beta, Windows 8.1 x64)

Note You need to log in before you can comment on or make changes to this bug.