Closed Bug 608589 Opened 13 years ago Closed 12 years ago

When not getting the tab closing animation's transitionend event in a reasonable amount of time, forcefully remove the tab and report an error

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b10
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: dao, Assigned: dao)

References

Details

(Whiteboard: [softblocker][fx4-fixed-bugday])

Attachments

(3 files, 9 obsolete files)

+++ 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
Attached image screenshot (obsolete) —
Blocks: 604735
Attached patch handle gracefully (obsolete) — Splinter Review
I'd like to land this to unblock bug 604735 and in case we don't find a proper fix for FF4.
Attachment #488663 - Flags: review?(gavin.sharp)
Switching to NS_ASSERT to make the failure obvious in nightlies... People don't look at the error console all the time.
Attachment #488663 - Attachment is obsolete: true
Attachment #488665 - Flags: review?(gavin.sharp)
Attachment #488663 - Flags: review?(gavin.sharp)
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?
Maybe some pointer is sometimes set to wrong tab?
This happened again to me today on about:addons using tab's close button.
(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.
No longer blocks: 604735
OS: Windows XP → All
Assignee: nobody → dao
Assignee: dao → nobody
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?
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.
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 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.
Attachment #488665 - Flags: review?(gavin.sharp) → review+
Comment on attachment 488665 [details] [diff] [review]
handle gracefully (checked in)

http://hg.mozilla.org/mozilla-central/rev/dba2dd6564d4
Attachment #488665 - Attachment description: handle gracefully → handle gracefully (checked in)
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?).
Is the assertion supposed to show up in an alert box every time it fails?
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?
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...
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.
Attached image Screenshot of assertion error. (obsolete) —
Got this while browsing.
Attached image yet another screenshot (obsolete) —
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).
(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>.
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)
I'm hitting the assertion quite a bit today, but I'm also still seeing some unclosed closed tabs.
Whiteboard: qa assist
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)
Attached image not sure that is right bug (obsolete) —
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?
(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
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)
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?
(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.
(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.
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!
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;
}
Attached image Another one. (obsolete) —
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?
(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.
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?
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.
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.
Attached image Screenshot alert (obsolete) —
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
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.
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)."
(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.
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)
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.
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)
Hit this today with a different number, so reporting it in case it's relevant.

Stack Trace: 
0:([object XULElement],[object XULElement],1413)
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.
Attached image Another example (2011-01-07) (obsolete) —
(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.
(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.
I just encountered this bug for the first time, using latest nightly, default theme (I got the assert message).
(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
I can confirm comment 59 on Windows XP.
(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.
Tab animation(browser.tabs.animate) should be disabled until this bug is fixed. It feels really annoying.
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
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
(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
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)
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.
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.
Also how is hardware acceleration involved here? Does it more often happen with enabled h/w acceleration?
@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.
(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.
(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.
(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.
The popup notification really needs to vanish before beta9's public release
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.
People will just turn off animated tabs or revert rather than put up with the annoyance of that popup, though, alas
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.
Whiteboard: qa assist → qa assist [softblocker]
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.
(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.
Attached patch remove assertion dialog (obsolete) — Splinter Review
We could also just wait for bug 613888 (which should be fixed soon) and then just remove this entirely.
Attachment #487225 - Attachment is obsolete: true
Attachment #499733 - Attachment is obsolete: true
Attachment #499737 - Attachment is obsolete: true
Attachment #500279 - Attachment is obsolete: true
Attachment #500606 - Attachment is obsolete: true
Attachment #500877 - Attachment is obsolete: true
Attachment #502202 - Attachment is obsolete: true
Attachment #503324 - Flags: review?(dao)
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.
Attachment #503324 - Attachment description: patch → remove assertion dialog
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.
I had a hard time triggering this, but when it happened, the computed max width was 250px...
Attachment #503457 - Flags: review?(gavin.sharp)
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)
Attachment #503457 - Flags: review?(gavin.sharp) → review+
Comment on attachment 503457 [details] [diff] [review]
avoid false positives (checked in)

http://hg.mozilla.org/mozilla-central/rev/f24f049857a5
Attachment #503457 - Attachment description: avoid false positives → avoid false positives (checked in)
Bug 613888 landed today, so if it was the cause of this bug, this might improve starting in tomorrow's mozilla-central nightlies.
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)
I've been unable to reproduce this with limited testing with the latest nightly on Windows.

Looking good so far.
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
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.
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.
I forgot to add: Firefox 4.0b9 on Windows XP.
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
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
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.
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.
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.
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)
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.
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.
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.
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.
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
(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.
(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.
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?
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: qa assist [softblocker] → qa assist [softblocker] [fixed by bug 613888]
Target Milestone: --- → Firefox 4.0b10
But the assert will be removed or disabled before FF4 is released, right?
It won't show up in release builds. NS_ASSERT takes care of that.
(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.
(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/
Status: RESOLVED → VERIFIED
Keywords: qawanted
Whiteboard: qa assist [softblocker] [fixed by bug 613888] → [softblocker][fixed by bug 613888][fx4-fixed-bugday]
Keywords: qawanted
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
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.
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.
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.
(In reply to comment #111)
> It won't show up in release builds. NS_ASSERT takes care of that.

What flag disables NS_ASSERT?
(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.
Depends on: 641090
No longer depends on: 641090
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
I had that issue too
It seems that this bug isn't fixed
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.
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;
}
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
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.
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.
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).
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.
@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.
Just got this bug pop-up as well after closing a tab.
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
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)
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
As requested in comment 130, please file a new bug. Thanks.
Status: REOPENED → RESOLVED
Closed: 13 years ago12 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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.
(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.
Mike, I've filed bug 708912 (I've reproduced it in a new profile).
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)"
(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?
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 :(
(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.
FF21a1
Flags: sec-review?
Flags: needinfo?
Flags: in-testsuite?
Flags: in-qa-testsuite?
Flags: in-moztrap?
Flags: in-litmus?
Flags: sec-review?
Flags: needinfo?
Flags: in-testsuite?
Flags: in-qa-testsuite?
Flags: in-moztrap?
Flags: in-litmus?
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?
I got this now too. Time to reopen the bug?
Or rather need to remove the assertion alert since the tab closed..
This was fixed a long time ago. If it's come back then you need to file a new bug report.
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])
(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.
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?
Assignee: nobody → dao
Summary: Tab fails to close, waiting for the closing animation's transitionend event → When not getting the tab closing animation's transitionend event in a reasonable amount of time, forcefully remove the tab and report an error
Whiteboard: [softblocker][fixed by bug 613888][fx4-fixed-bugday] → [softblocker][fx4-fixed-bugday]
Attachment #503324 - Attachment is obsolete: true
(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)
You need to log in before you can comment on or make changes to this bug.