1262283 - tps needs to wait for TabSwitchDone before moving on to the next subtest

Status: RESOLVED FIXED

(Testing :: Talos, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

tps switches between a bunch of tabs, one after the other. After it's done switching to a tab, it switches to an about:blank tab to try to reach a "steady painting state", and then switches to the next tab, and so on.

Unfortunately, it's not waiting for the TabSwitchDone event before proceeding to the next tab switch. This means that we're not giving enough time for the async tab switcher to destroy itself, which also means deactivating the DocShells of the tabs we've switched away from.

This only affects the e10s case because the non-e10s case has sync tab switching.

Essentially, with the current test on e10s, we're keeping every DocShell alive as we move through each tab, which means that each one continues to get paint updates.

We should wait for the TabSwitchDone event which gets fired once the switcher destroys itself. That should give us a better sense of how e10s compares to non-e10s in tab switching with a more common scenario[1].

[1]: The only case I can think of where the current test behaviour reflects actual usage is if the user is holding down ctrl-tab and flipping through a hundred tabs. I don't think that's really something we need to optimize for.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6f5c015594aa

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Hey billm, my first instinct here is to make it so that tps waits for TabSwitchDone before continuing on to the next tab switch.

Before I do that though, can you remind me why we keep the docshells of the background tabs active once we've switched away from them? Is that to account for the possibility that we'll switch back before the initial switch has an opportunity to complete?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c180f4eb24cd

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #2)
> Before I do that though, can you remind me why we keep the docshells of the
> background tabs active once we've switched away from them? Is that to
> account for the possibility that we'll switch back before the initial switch
> has an opportunity to complete?

Well, the unload timer exists in case someone switches tabs and then quickly switches back. I tend to do that a lot when writing something while consulting a different web page. (I use Ctrl-Tab, which mimics the Windows Alt-Tab behavior because of some pref I have set.) This may not be a common case though.

In general we can't declare the tab switch to be done until the unload has been acknowledged though. Otherwise we get weird bugs where we assume a tab is inactive but actually it is active, although about to be deactivated.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

The tps test modifications I made in bug 1261152 now wait for the TabSwitchDone event, so this is now fixed.