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.
When our flexibilities sum to a fraction < 1, we clamp the free space to be no
greater than that same fraction of the original free space. This effectively
makes us treat a flexibility of e.g. "0.01" as "1% of the original free space"
in that sort of situation (while still treating it as a normal flex factor if
the sum of the flex factors is greater than 1).
The phrase "flex weight" used to be a term defined in the spec, but it's
long-since been replaced with "flex factor" and "scaled flex factor".
I'm now using the term "weight" to mean "flex factor, with any necessary scaling already done, ready to be used as a weight for apportioning free space".
I'm dropping the "flex" modifier from "flex weight" both for brevity & to make
it more clearly-distinguishable from actual "flex factor" usages in the code.
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.
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.
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
Without this patch, when changing the x/y attributes of svg:use, innerSVG and foreignObject, we were relying on the transform changes of the children to trigger the right invalidations. However, changes to those attributes can also change the filter region. And there's a difference between moving children in a fixed filter region and moving the filter region along with the children: In the first case, we wouldn't need to invalidate anything outside the old filter region, because those parts of the children would be clipped away anyway. But when the filter region changes, we need to invalidate both the old and the new filter region. Also, when the filter has primitives without inputs, e.g. flood or turbulence, the filtered frame needs to be invalidate even if it has no children.
This function calculates the offset between "bounding box frame space" and "user space" for SVG frames. For non-SVG frames it returns no offset.
It's crucial that this is consistent with what nsSVGUtils::GetBBox does.
nsFilterInstance has several methods that are called by consumers before the actual painting, e.g. to calculate post filter extents or invalidation regions. Those nsFilterInstance APIs have their input and output values in "bounding box frame space" coordinates, but if the filter units are "objectBoundingBox", then those methods also do calculations involving the result of nsSVGUtils::GetBBox. So a consistent conversion is very important.
There are three spaces that nsSVGIntegrationUtils needs to convert between. I'll call them "frame space", "bounding box frame space" and "user space".
"Bounding box frame space" has its origin at the top left of the union of a frame's border boxes over all continuations.
For SVG frames, "frame space" and "bounding box frame space" are the same because SVG frames don't have multiple continuations.
For non-SVG frames, "bounding box frame space" and "user space" are the same.
However, for SVG frames, "bounding box frame space" and "user space" are different! For example, for a <rect x="100" y="100">, the point 0,0 in frame space is at the rect's top left corner, but the point 0,0 in user space is 100,100 pixels away from the rect's corner.
nsSVGIntegrationUtils::GetOffsetToUserSpace took the non-SVG viewpoint, but it's misleading for SVG frames.
- The condition described in the FIXME comment is already handled by
GetNearestBlockContainer in nsFrame.cpp (helper for
nsIFrame::GetContainingBlock).
