Currently, if a new tab is opened while the user is already dragging a tab button, we just safely ignore it and then layout a button for it when dragging has finished. Ideally, we should dynamically layout a new button for the tab during the drag session right when it opens. I was close at solving this over on bug 472771 by calling |layoutButtonsPreservingVisibility...| and skipping the dragging tab, but it would break when the tab buttons had to change size to account for the new total number of tabs displaying, even though I attempted to account for it. I know the reason it broke was caused by animating background tabs that were still moving before re-layout; they seem to slide into the correct frame location but offset with the old button sizes. It's strange, because I attempted to stop all animations when laying them out :-/. Note that we do handle removing a tab item properly during a drag, whether it's the one that is dragging or just a background tab. If it's the one dragging, we end the session, and a removed background tab causes the others to slide and fill up it's position, all while a tab is still dragging.
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.