The homescreen stays visible causing noticeable performance loss.

For the appWindows in the stack, we call enterTaskManager() on them when we render the card. That causes them to transition to closed state. For homescreen, we handle cardviewbeforeshow in HomescreenLauncher and call fadeOut() on the homescreen. But, because homescreen is active in this use case, fadeOut is a no-op. We could call close() on the homescreen when cardsviewbeforeshow fires, but messing with homescreen state makes me nervous at this stage of the game. I'm thinking of implementing a enterTaskManager on HomescreenWindow that just explicitly adds the 'fadeout' class.

This breaks the symmetry of the fadeIn/fadeOut calls but looks to give us the right result?

Based on the bug title, perhaps you would prefer if enterTaskManager on HomescreenWindow did this.close('immediate')? I see no handlers for the 'homescreenclose' event that would complicate this. I'm trying to think if there would be other unwanted side-effects?

(In reply to Sam Foster [:sfoster] from comment #3) > Based on the bug title, perhaps you would prefer if enterTaskManager on > HomescreenWindow did this.close('immediate')? I see no handlers for the > 'homescreenclose' event that would complicate this. I'm trying to think if > there would be other unwanted side-effects? I don't think it should. The issue with the current approach is that when you select an app from the cardsview the homescreen fades in again (cardviewbeforeclose) so it'll appear between the sheets when you edge swipe. In fact I think the main issue here is that the appopening/appopened events are being raced by the cardviewbeforeclose event.

The code this bug refers to was long since re-worked in other bugs