Enable nglayout.debug.paint_flashing;true Go to microsoft.com Note the main content div flickers every time the slideshow changes, or if you move the mouse over the slideshow controls (the back/pause/forward buttons). No idea why, but could be because the contents of the slideshow div overflow the visible area and even the main content div? Anyway, bz said it would require a reduced testcase.
Looks like this is caused by "the float invalidation bug", I think I've been using bug 546362 to track that, but its description/summary aren't the best for that.
Disabling float on slideshows parent elements reduces the flickering significantly. It can be tested e.g. by running this script in a console: for (var e = document.getElementById('ctl00_ctl14_BodyRepeater_ctl00_ctl01_'+ 'ColumnRepeater_ctl00_RowRepeater_ctl00_CellRepeater_ctl00_Cell'); e; e = e.parentNode) e.style.cssFloat = 'none'; So it seems to be the same issue as in bug 716747 (that also depends on bug 546362). But when the slide animation begins and ends the remaining floated elements (i.e. elsewhere in the tree) also flash a single time. This might be triggered by the element removal/addition that happen at that time.
So. I rechecked microsoft.com to see if it was still happening. Seeing the weirdest thing. w/ paint flashing enabled, entire browser pulsates regularly (once a second?) This includes the tab area. If I move my mouse over the new slideshow on microsoft.com, the pulsating stops. Now. Oddly, this also happens on about:config (entire browser pulsating) on about:blank, only the tab bar pulsates. on about:newtab it is the entire browser again. Same ~ once per second. So, I don't think microsoft.com's new slideshow suffers from the original issue anymore. There is however some other totally different weirdness going on in this nightly (I do have layers acceleration force enabled)
No longer seeing any of the behaviour from comment #3 in latest nightly.
I can't reproduce this issue with the latest Nightly (build ID: 20130912030201) on Ubuntu 12.10 32bit, using the STR from comment 0 and comment 3. Closing this as WFM, since the reporter didn't reproduce it again, in comment 4. Please reopen this bug if you can still reproduce it. Thanks!