1083435 - Allow nsStyleSet::ResolveStyleByAddingRules() to set eSkipParentDisplayBasedStyleFixup

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Holbert [:dholbert]]

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.

Comment 1

[Daniel Holbert [:dholbert]]

(I attached a probably-incomplete fix for this (using a bool) over on bug 1081072, in attachment 8503455 [details] [diff] [review].)

Comment 2

[Daniel Holbert [:dholbert]]

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.)