Steps to reproduce: 1. Use a build from the graphics branch. https://treeherder.mozilla.org/#/jobs?repo=graphics 2. Go to https://www.w3.org/conf/2013sf/ and wait for it to load. 3. Move your mouse over the "Sponsors" navigation button in the top left corner. 4. Do a fling scroll downwards. 5. While it's still scrolling, move your mouse to the right, across the other navigation buttons and off the fixed navigation bar. For some of the buttons, the text is now missing.

So the underlying problem here is that WrapInWrapList conditionally creates a wrap list, only if there are multiple items. If we do a partial build, we can end up with one item (and no wrap list), where the full build had multiple items (within a wrap list). We now have matching items at different nesting depths (and without the old ones being all marked invalid), and merging gets confused. Making it unconditional is hard since it breaks nsDisplayPerspective (as the comment in there explains), but it also breaks merging. We no longer end up with nsDisplayOpacity siblings, we get nsDisplayWrapList siblings, each with a single nsDisplayOpacity child. Our merging code doesn't handle this. I tried checking if the current frame was a stacking context, and if we had already created a wrapping item for that stacking context (a single item, return a child list from GetChildren), and skip the wrap list if so, otherwise always create one. This also fails because nsDisplayMask/nsDisplayFilter meet this description, but we also end up with nsDisplayScrollInfoLayer as a sibling, and thus we really need a wrap list. I'm a bit confused though, since both mask/filter implement CanMerge, yet it can't be working if they end up with wrap lists around them. I can add code to detect this specific case and preserve the old behaviour (always use wrap list for filter/mask), but do we want to worry about merging?

Rather than creating wrap lists if there are multiple items (which can change during a partial build), try to always build them (or not) regardless of which items got built.

Can you add a test for this?

The attached patch does not apply cleanly anymore, here is a rebased version: https://pastebin.mozilla.org/9071128 This patch alone does does not seem to fix https://www.w3.org/conf/2013sf/.

Took a while, but managed to get a decent minimal testcase. This fails rendering, and then crashes pretty quickly without the patch, works great with! This will fix quite a lot of our outstanding crash issues, and I think we'll be usable in the Nightly after this lands.

Comment on attachment 8921659 [details] [diff] [review] Create WrapLists unconditionally Review of attachment 8921659 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for adding the test! ::: layout/generic/nsFrame.cpp @@ +3131,5 @@ > > aList->AppendToTop(&resultList); > } > > static nsDisplayItem* A comment about the purpose of aCanSkipWrapList would be nice to have here.

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/8990a530c1ea Don't make the decision to build nsDisplayWrapList based on the number of child items, since this can vary when doing partial display list builds. r=mstange