1441902 - Consider running preActions and postActions for requestTab

Status: RESOLVED INVALID

(Firefox :: Tabbed Browser, enhancement)

Description

[Mike Conley (:mconley) (:⚙️) (PTO June 8 - 12)]

We run preActions and postActions for updating async tab switcher state every time we service events in the handleEvent function. The idea is that the tab switcher internal state is often impacted by events, and so that's a perfect time to update that state, and to reflect that state to the user if needs be, visually.

We don't, it seems, update state surrounding requestTab, and I find that strange. This means that if the tab that we're requesting is STATE_LOADED, then we have to wait for the next event we service (probably a MozAfterPaint?) to update the displayed tab. That seems strange.

Maybe we can run preActions and postActions before and after requestTab, respectively.

Comment 1

[Alex Thayer [:alexical] (she/her)]

I'm a bit confused - are you accounting for the preActions and postActions that get run in requestTab through suppressDisplayPortAndQueueUnload?

Comment 2

[Mike Conley (:mconley) (:⚙️) (PTO June 8 - 12)]

(In reply to Doug Thayer [:dthayer] from comment #1)
> I'm a bit confused - are you accounting for the preActions and postActions
> that get run in requestTab through suppressDisplayPortAndQueueUnload?

Ah, I'd missed that they were being called there. Thanks!