I was investigating an intermittent macOS opt test-verify failure for my test in bug 1627012, and narrowed it down to some behaviour that I think might be an edge case-y bug in the code. For now I've worked around it in the test, but it might need to be dug into a little more and fixed in the code.

The test does the following:

• pinch zoom in with touch events
• wait for everything to stabilize
• open a new tab, wait for it to paint, and then close it
• ensure the visual viewport here is the same as before the new tab was opened.

During the zoom animation, APZ can send multiple repaint requests to the main thread. Let's say it sends two, the first one with visual scroll offset V1 and the second with visual offset V2. After the main thread receives V1, it (for reasons I'm not entirely sure, but probably don't matter) does a repaint and sends a layer tree (with metrics reflecting V1) back to APZ. That works fine. After the main thread receives V2, it does not do a repaint.

After the new tab is closed, APZ gets a NotifyLayersUpdated call that seems to use a "cached" layer tree, in that the metrics on it have visual scroll offset V1. I've verified that ComputeScrollMetadata is not called between the new tab closing and APZ getting the NotifyLayersUpdated call, so that's why I assume the layer tree is cached. I'm assuming this is from the async tab switching stuff in bug 1176019, but I haven't confirmed that.

At any rate, APZ will accept this cached V1 visual scroll offset and apply it, and then send a repaint request back to the main thread with that same V1 visual scroll offset, which the clobbers V2 on the main-thread. So this ends up with the visual viewport not being properly restored after the tab switch back.

I worked around this in the test by forcing a new layer tree to the compositor before opening the new tab, but it probably needs a better fix.