View Single Post
Old 12-22-2019, 09:39 PM   #71
KevinH
Wizard
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 4,288
Karma: 2621140
Join Date: Nov 2009
Device: many
Found it. It was related to the fast tab closing fix. The current code works if you make the tab you are about to close, the current tab first. It assumes the closing of a tab always forces a new tab to become current.

This is of course is not what happens in this case at all.

So we need to change the logic to handle the case where the tab being closed is the current tab, and the case where the tab being closed is not the current tab meaning no tab switch is needed and therefore no break and make of signal connections.

I have a fix that seems to work in this case but it may break the fast close of tabs. I really need to sleep on this change and run more tests in the morning to see if it causes the old bug to return.

If not I will commit it.

Thank you to everyone who helped report the bug, figured out how to recreate it consistently, reported the platforms it failed on, etc. Without your help I don't think we would have been able to find the bug so quickly!
KevinH is offline   Reply With Quote