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)
Firefox
Tabbed Browser
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)
1.04 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
815 bytes,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
677.06 KB,
image/png
|
Details |
+++ 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
Assignee | ||
Comment 1•13 years ago
|
||
Assignee | ||
Comment 2•13 years ago
|
||
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)
Assignee | ||
Comment 3•13 years ago
|
||
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)
Comment 6•13 years ago
|
||
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•13 years ago
|
||
Maybe some pointer is sometimes set to wrong tab?
Comment 9•13 years ago
|
||
This happened again to me today on about:addons using tab's close button.
Comment 10•13 years ago
|
||
(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.
Assignee | ||
Updated•13 years ago
|
OS: Windows XP → All
Updated•13 years ago
|
Assignee: nobody → dao
Assignee | ||
Updated•13 years ago
|
Assignee: dao → nobody
Comment 11•13 years ago
|
||
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?
Assignee | ||
Comment 12•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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+
Assignee | ||
Comment 15•13 years ago
|
||
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)
Comment 16•13 years ago
|
||
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?
Comment 19•13 years ago
|
||
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.
Comment 21•13 years ago
|
||
Got this while browsing.
Comment 22•13 years ago
|
||
Comment 23•13 years ago
|
||
http://img826.imageshack.us/img826/5156/yetfail.png http://img811.imageshack.us/img811/6377/yetfail2.png
Comment 24•13 years ago
|
||
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).
Assignee | ||
Comment 25•13 years ago
|
||
(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•13 years ago
|
||
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.
Updated•13 years ago
|
Whiteboard: qa assist
Comment 29•13 years ago
|
||
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•13 years ago
|
||
Comment 31•13 years ago
|
||
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?
Assignee | ||
Comment 32•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
(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.
Assignee | ||
Comment 36•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Comment 40•13 years ago
|
||
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?
Assignee | ||
Comment 41•13 years ago
|
||
(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•13 years ago
|
||
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?
Assignee | ||
Comment 43•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Comment 46•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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)."
Assignee | ||
Comment 49•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Assignee | ||
Comment 56•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
I just encountered this bug for the first time, using latest nightly, default theme (I got the assert message).
Comment 59•13 years ago
|
||
(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•13 years ago
|
||
I can confirm comment 59 on Windows XP.
Comment 61•13 years ago
|
||
(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•13 years ago
|
||
Tab animation(browser.tabs.animate) should be disabled until this bug is fixed. It feels really annoying.
Comment 63•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Also how is hardware acceleration involved here? Does it more often happen with enabled h/w acceleration?
Comment 70•13 years ago
|
||
@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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
The popup notification really needs to vanish before beta9's public release
Comment 75•13 years ago
|
||
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•13 years ago
|
||
People will just turn off animated tabs or revert rather than put up with the annoyance of that popup, though, alas
Comment 77•13 years ago
|
||
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.
Updated•13 years ago
|
Whiteboard: qa assist → qa assist [softblocker]
Comment 78•13 years ago
|
||
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.
Assignee | ||
Comment 79•13 years ago
|
||
(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•13 years ago
|
||
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)
Comment 81•13 years ago
|
||
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.
Updated•13 years ago
|
Attachment #503324 -
Attachment description: patch → remove assertion dialog
Assignee | ||
Comment 82•13 years ago
|
||
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.
Updated•13 years ago
|
Attachment #503324 -
Flags: review?(dao)
Assignee | ||
Comment 83•13 years ago
|
||
I had a hard time triggering this, but when it happened, the computed max width was 250px...
Attachment #503457 -
Flags: review?(gavin.sharp)
Comment 84•13 years ago
|
||
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)
Updated•13 years ago
|
Attachment #503457 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Comment 85•13 years ago
|
||
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)
Comment 86•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
I've been unable to reproduce this with limited testing with the latest nightly on Windows. Looking good so far.
Comment 90•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
I forgot to add: Firefox 4.0b9 on Windows XP.
Comment 95•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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
Assignee | ||
Comment 106•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
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?
Assignee | ||
Comment 109•13 years ago
|
||
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
Comment 110•13 years ago
|
||
But the assert will be removed or disabled before FF4 is released, right?
Assignee | ||
Comment 111•13 years ago
|
||
It won't show up in release builds. NS_ASSERT takes care of that.
Comment 112•13 years ago
|
||
(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.
Assignee | ||
Comment 113•13 years ago
|
||
(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]
Comment 114•13 years ago
|
||
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Comment 115•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Comment 119•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
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.
Comment 124•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
@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•12 years ago
|
||
Just got this bug pop-up as well after closing a tab.
Comment 132•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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 → ---
Comment 135•12 years ago
|
||
As requested in comment 130, please file a new bug. Thanks.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
Comment 136•12 years ago
|
||
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.
Assignee | ||
Comment 137•12 years ago
|
||
(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•12 years ago
|
||
Mike, I've filed bug 708912 (I've reproduced it in a new profile).
Comment 139•12 years ago
|
||
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)"
Assignee | ||
Comment 140•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
(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•11 years ago
|
||
FF21a1
Flags: sec-review?
Flags: needinfo?
Flags: in-testsuite?
Flags: in-qa-testsuite?
Flags: in-moztrap?
Flags: in-litmus?
Assignee | ||
Updated•11 years ago
|
Flags: sec-review?
Flags: needinfo?
Flags: in-testsuite?
Flags: in-qa-testsuite?
Flags: in-moztrap?
Flags: in-litmus?
Comment 144•10 years ago
|
||
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•10 years ago
|
||
I got this now too. Time to reopen the bug?
Comment 146•10 years ago
|
||
Or rather need to remove the assertion alert since the tab closed..
Comment 147•10 years ago
|
||
This was fixed a long time ago. If it's come back then you need to file a new bug report.
Comment 148•10 years ago
|
||
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•10 years ago
|
||
(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•10 years ago
|
||
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 | ||
Updated•10 years ago
|
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]
Assignee | ||
Updated•10 years ago
|
Attachment #503324 -
Attachment is obsolete: true
Comment 151•10 years ago
|
||
(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.
Description
•