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

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Dão Gottwald [:dao]]

+++ 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]]

Attachment: screenshot

Comment 2

[Dão Gottwald [:dao]]

Attachment: 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]]

Attachment: 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 6

[Andreas Jung]

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 8

[Filip Zakrzewski]

Maybe some pointer is sometimes set to wrong tab?

Comment 9

[[not reading bugmail]]

This happened again to me today on about:addons using tab's close button.

Comment 10

[Stefan Ring]

(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

[(no longer active)]

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]]

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]

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: [e-mail]]]

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]]

Comment on attachment 488665 [details] [diff] [review]
handle gracefully (checked in)

http://hg.mozilla.org/mozilla-central/rev/dba2dd6564d4

Comment 16

[Johannes Pfrang [:johnp]]

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) (Not reading bugmail; email directly if needed)]

Is the assertion supposed to show up in an alert box every time it fails?

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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: [e-mail]]]

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) (Not reading bugmail; email directly if needed)]

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]]

Attachment: Screenshot of assertion error.

Got this while browsing.

Comment 22

[Oleg]

Attachment: yet another screenshot

Comment 23

[Oleg]

http://img826.imageshack.us/img826/5156/yetfail.png

http://img811.imageshack.us/img811/6377/yetfail2.png

Comment 24

[Chris B.]

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]]

(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][⌚️UTC+1]]

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) (Not reading bugmail; email directly if needed)]

I'm hitting the assertion quite a bit today, but I'm also still seeing some unclosed closed tabs.

Comment 29

[David Tenser [:djst]]

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]

Attachment: not sure that is right bug

Comment 31

[AL]

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]]

(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]]

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 C]

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]

(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]]

(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]

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]

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]]

Attachment: Another one.

Comment 40

[patrickjdempsey]

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]]

(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]

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]]

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]

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]

Attachment: Screenshot alert

Comment 46

[Remy Mentasti]

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][[e-mail]]]

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]

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]]

(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]]

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 [inactive]]

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]

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 bugmail, email directly)]

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][⌚️UTC+1]]

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]

Attachment: Another example (2011-01-07)

Comment 56

[Dão Gottwald [:dao]]

(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][⌚️UTC+1]]

(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]

I just encountered this bug for the first time, using latest nightly, default theme (I got the assert message).

Comment 59

[LegNeato]

(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]

I can confirm comment 59 on Windows XP.

Comment 61

[Daniel C]

(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]]

Tab animation(browser.tabs.animate) should be disabled until this bug is fixed. It feels really annoying.

Comment 63

[Raul Nicolae Malea]

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]]

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] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(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]

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][⌚️UTC+1]]

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.]

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][⌚️UTC+1]]

Also how is hardware acceleration involved here? Does it more often happen with enabled h/w acceleration?

Comment 70

[Daniel Buchner [:dbuc]]

@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]

(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.]

(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]

(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]

The popup notification really needs to vanish before beta9's public release

Comment 75

[nonoitall]

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]

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]]

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: [e-mail]]]

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]]

(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: [e-mail]]]

Attachment: 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: [e-mail]]]

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]]

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]]

Attachment: 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]

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]]

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:]

Bug 613888 landed today, so if it was the cause of this bug, this might improve starting in tomorrow's mozilla-central nightlies.

Comment 88

[Abdoulah]

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]

I've been unable to reproduce this with limited testing with the latest nightly on Windows.

Looking good so far.

Comment 90

[Kuno Meyer]

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 Sokoloff]

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]

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]

I forgot to add: Firefox 4.0b9 on Windows XP.

Comment 95

[Stephen]

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]

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]

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]

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

[Lex Robinson]

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]]

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]

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]

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]

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]

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]

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]]

(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][[e-mail]]]

(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)]

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]]

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][[e-mail]]]

But the assert will be removed or disabled before FF4 is released, right?

Comment 111

[Dão Gottwald [:dao]]

It won't show up in release builds. NS_ASSERT takes care of that.

Comment 112

[patrickjdempsey]

(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]]

(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

[Aleksei Perepelkin [:chaos]]

Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre

Comment 115

[David Tenser [:djst]]

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]

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.]

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.]

Attachment: 3-2-11 Assertion Failed Message

Comment 119

[Olli Pettay [:smaug][[e-mail]]]

(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

[(no longer active)]

(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]

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]

I had that issue too
It seems that this bug isn't fixed

Comment 123

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

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 (dead)]

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]]

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]]

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]

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

[u279076]

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]

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

[u279076]

@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]

Just got this bug pop-up as well after closing a tab.

Comment 132

[Theliel]

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]]

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]]

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

[u279076]

As requested in comment 130, please file a new bug. Thanks.

Comment 136

[Mike Hommey [:glandium]]

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]]

(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]]

Mike, I've filed bug 708912 (I've reproduced it in a new profile).

Comment 139

[Rodrigo Navarrete]

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]]

(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]

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]

(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]

FF21a1

Comment 144

[alex_mayorga]

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]

I got this now too. Time to reopen the bug?

Comment 146

[Anshu Prateek]

Or rather need to remove the assertion alert since the tab closed..

Comment 147

[u279076]

This was fixed a long time ago. If it's come back then you need to file a new bug report.

Comment 148

[timeless]

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

[u279076]

(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]

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]]

(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)