- When OverflowChangedTracker::Flush() coalesces multiple changes
simultaneously, it was possible to downgrade parent frames from
CHILDREN_AND_PARENT_CHANGED to CHILDREN_CHANGED, resulting in an incomplete
update.
- This patch ensures that the strongest ChangeKind is retained when cascading
up to parent frames.
- Added crashtest to ensure that the "Should be starting from the first
continuation" assertion is not fired when recalculating the position of a
sticky with ib-split siblings.
- RestyleManager::RecomputePosition now calls
StickyScrollContainer::PositionContinuation with the first continuation
or ib-split-sibling of the passed frame, as PositionContinuations will
update all continuations at once, and expects the first continuation
to be passed in.
The opaque region of the background image display item was incorrectly clipped to the viewport size, offset by the scroll position. nsDisplayBackgroundImage::GetBoundsInternal has a special case for canvas frames that sets the clip area to the whole canvas area; this patch does the same for GetInsideClipRegion.
To get layer pixels (doesn't matter which layer, they are all the same to layout because there is no async transform) you need to multiply by the cumulative resolution.
The fact that our units system says that multiplying by the parent resolution will work is a problem with our units system.
Before bug 968805, none of the callers would reach this branch. The callers in
nsContentDLF.cpp call LoadStart immediately after constructing the
nsDocumentViewer, so they hit the !mDocument case, and the comparison was
always false for the caller in nsHTMLDocument::Open, as it passed an
nsIHTMLDocument pointer, so the nsISupports pointers being compared were
always different. (XPCOM rules require SameCOMIdentity in this case, to avoid
exactly this issue.)
I tested that the removed code was never reached after a backout of bug 968805.
This is needed to avoid hitting the assertion "Why did this not get
handled while processing mRestyleRoots?" in CollectRestyles, because we
have a restyle posted for a frame that has the NEEDS_FRAME bit flag set.
Choosing a frame that is scrolled along with the inactive layer results in a fixed offset between the two, so the transform that we set on the thebes layer in the basic layer manager of the inactive layer doesn't change when the page is scrolled.
--HG--
extra : rebase_source : 9b7996e2979e7d833aaddada2eebdd3c15ab621e
Also NotifyRenderingChanged was on the canvas background color item, not the background image item.
Bug 818643 was a problem where the cache didn't get purged enough, but the fix meant we basically always purged the cached and never got to use it, making it useless. It meant that we purged the cache anytime the item has any type of invalidation whatsoever, even if the item would be drawn the same but the layer contents needed to be invalidated so that it would be redrawn (ie due to staying at the same position on screen but a different position in the layer).
This is really hacky, but NotifyRenderingChanged is only observed on one type of display item. So we just isolate the case where the only thing that changed is the offset (due to scrolling) and skip the NotifyRenderingChanged in that case.
