Bugzilla

There is a timing problem that is not trivial to address here.
We're setting an attribute on the tab, that is supposed to start the tab animation, and there is code that depends on the tab animation happening.
There is a timing issue for which when new tab content is preloaded setting the attribute doesn't kick off the animation. As a consequence we also alternatively not preload new tab.

Before the patch landed here, I could clearly see the tab animation being completely skipped every other time (`transitionend` not happening), and dumping just after `this._createBrowserForTab` I could alternatively see `usingPreloadedContent: false`.
After the patch I see the tab animation every time, and I constantly see `transitionend` happening and  `usingPreloadedContent: true` being set.

Also in your video I see the tab animation happening constantly, while before it was completely skipped (tab appearing from nowhere) every other time.

The animation may not be 100% smooth, because to address the timing problem itself we are eating up 2 frames of it.
The newtab flicker may also be a problem related to preloading. There is surely more to investigate there.

Based on this, I think the original concern of the animation being skipped and causing newtab to not be preloaded every other time is addressed. For QA is a bit more complicate to assess that, as you are not supposed to dump js objects, thus I'd suggest to stick to ensuring the animation happens, compared to the previous alternate state, and ensure the situation improved sufficiently.
The situation should have improved, but I agree there's still something off.

As there are a few more things to investigate and understand, I'll file a follow-up bug where we can ask people with deeper knowledge about Layout and preloaded new tab for an opinion. That should also investigate this new tab flicker.

There is a timing problem that is not trivial to address here.
We're setting an attribute on the tab, that is supposed to start the tab animation, and there is code that depends on the tab animation happening.
There is a timing issue for which when new tab content is preloaded setting the attribute doesn't kick off the animation. As a consequence we also alternatively not preload new tab.

Before the patch landed here, I could clearly see the tab animation being completely skipped every other time (`transitionend` not happening), and dumping just after `this._createBrowserForTab` I could alternatively see `usingPreloadedContent: false`.
After the patch I see the tab animation every time, and I constantly see `transitionend` happening and  `usingPreloadedContent: true` being set.

Also in your video I see the tab animation happening constantly, while before it was completely skipped (tab appearing from nowhere) every other time.

The animation may not be 100% smooth, because to address the timing problem itself we are eating up 2 frames of it.
The newtab flicker may also be a problem related to preloading. There is surely more to investigate there.

Based on this, I think the original concern of the animation being skipped and causing newtab to not be preloaded every other time is addressed. For QA is a bit more complicate to assess that, as you are not supposed to dump js objects, thus I'd suggest to stick to ensuring the animation happens, compared to the previous alternate state.
The situation should have improved sufficiently, but I agree there's still something off.

As there are a few more things to investigate and understand, I'll file a follow-up bug where we can ask people with deeper knowledge about Layout and preloaded new tab for an opinion. That should also investigate this new tab flicker.