We were under the assumption that the painting of tabs and friends during the TART test was the same as if using the keyboard or mouse. That appears to not be the case - at least on Windows XP. Here's a video of me opening and closing a bunch of tabs using the mouse and keyboard, with paint flashing on: http://screencast.com/t/6Oq4KGao6 and here's me running TART (no back-button tickle): http://screencast.com/t/5Zwd0qF9Fa Notice that the *whole navigator toolbox* is being repainted during the tab open and close. Also, if your initial thought was the pinned tab in the TART video, I can safely say that I tested that, and having a pinned tab did not cause the navigator toolbox to repaint when opening tabs with the keyboard or mouse.

More facts: 1) I am not able to reproduce this repainting on today's m-c Nightly. 2) This repainting is present at the first landing of the Australis curvy tabs for Windows XP. 3) I'm not able to reproduce this repainting on Windows 7 4) I haven't yet been able to slow-down the video, but it *appears* as if the repaint is happening just as the tab is being first opened.

So this happens on UX on XP but nowhere else (neither m-c on win7/xp, nor UX on win7), and it happens from the very first UX revision we can put our hands on. And on this first revision, TART shows that UX on xp is better than m-c on xp. Maybe there are bigger fish to fry?

I suggest we still investigate to see whether or not this repaint is entering our TART tests. If they are, they could possibly explain the discrepancy between Win 7 / Win 8's awesome performance[1], and Win XP's more mediocre performance[2]. [1]: http://compare-talos.mattn.ca/breakdown.html?oldTestIds=29253453&newTestIds=29253501&testName=tart&osName=Windows%207&server=graphs.mozilla.org [2]: http://compare-talos.mattn.ca/breakdown.html?oldTestIds=29253477&newTestIds=29253493,29268695,29268703,29268711&testName=tart&osName=Windows%20XP&server=graphs.mozilla.org * These compare results are from the push that landed the curvy tabs, compared against the m-c of the time.

Mike, who's owning this? I also think this is worth at least quick investigation.

I'm owning this. I've been looking at this today. It looks like this is somehow related to the tab label being updated - if I hide the tab label, the phenomenon disappears. I'm also able to reproduce this bug without TART if I set the newtab page to about:blank. -Mike

More facts: For an opt build that has the problem, it seems that a debug build for the same push does *not* show the problem.

It also seems related to the background: transparent that tabs.inc.css sets on tabbrowser-tab. Removing background: transparent seems to make the bug go away. I'm talking with :tn in #layout right now, trying to figure out what's up.

Since we can workaround this bug by setting the background to some colour, I've pushed a patch to try to do just that, in order to determine if / with what magnitude this affects our TART results for XP. UX baseline: https://tbpl.mozilla.org/?tree=Try&rev=033e5e91b9cf Patch: https://tbpl.mozilla.org/?tree=Try&rev=a99bfb260d22 Compare-talos link, when the patch build is ready: http://compare-talos.mattn.ca/?oldRevs=033e5e91b9cf&newRev=a99bfb260d22&server=graphs.mozilla.org&submit=true

The compare-talos data is a bit mystifying. It looks like the patch *did* have an effect on the TART results, but in the negative direction; my patch made things *worse*. And it mostly moved the needle on the DPI2 measurements. I've confirmed that, at least on my XP VM, the repainting issue is gone with that try build. So either: 1) My VM is not an accurate representation of what's going on on talos (and so I should try reproducing the bug on one of our talos loaners) 2) The repaint costs *less* than the cost of painting the backgrounds of the tabs red. And that's pretty strange. So I guess my next step here is to confirm that the talos machines are experiencing the bug.

Looks like this is no longer relevant due to bug 1130266.