BACKGROUND: Right now, in several nsStyleSet functions that resolve style contexts, we set a flag ("eSkipParentDisplayBasedStyleFixup") to make ApplyStyleFixups skip its flex-item blockification step. (We need this when resolving the style contexts of anonymous XUL elements that attach to an element with "display:flex" -- for example, scrollbars on a "display:flex; overflow:scroll" element.) nsStyleSet generally determines that this flag should be set by checking whether the passed-in element returns true from IsRootOfAnonymousSubtree() (which is a good signal that we shouldn't mess with its display value), or by checking mSkippingParentDisplayBasedStyleFixup on a passed-in nsTreeMatchContext (which the caller will have set for us). THE BUG: Right now, the method ResolveStyleByAddingRules has neither a pointer to the Element, nor a nsTreeMatchContext, so it does not know whether to set this flag. As demonstrated in bug 1081072, this can be problematic if we start a transition on a flex container's scrollbar. We end up calling ResolveStyleByAddingRules during the transition, and inadvertently adjust the scrollbar's "display" value via ApplyStyleFixups. So, we need to give ResolveStyleByAddingRules some signal (a bool, a "flags" parameter, or perhaps just a pointer to the Element in question) that lets it determine whether this flag should be set.
(I attached a probably-incomplete fix for this (using a bool) over on bug 1081072, in attachment 8503455 [details] [diff] [review].)
It's not clear to me how possible it is to actually trigger a mis-rendering from this bug, without doing slightly-sketchy stuff in chrome code. So, I probably won't prioritize this for the moment, unless we find ways to hit it. (In bug 1081072, we were hitting this as a result of making a manual tweak to a XUL scrollbar-button's style, which then [unintentionally] triggered a transition to start. Manual restyling of scrollbars is probably not something we should be doing lightly, let alone manual restyling with simultaneous transitions/animations on the scrollbars; so this probably isn't likely to come up again anytime soon from that sort of code-path.)
You need to log in before you can comment on or make changes to this bug.