Wrap the zoom item in the resolution item if we have both because we want the resolution scale applied on top of the app units per dev pixel conversion. Resolution is just a scale transform and app units per dev pixel affect layout, so conceptually the resolution gets applied after.
This means that the layer we create in nsSubDocumentFrame::BuildDisplayList becomes the scrollable layer for the document and we early early from ScrollFrameHelper::BuildDisplayList before it gets to the nsDisplayScrollLayer creation.
While it seems a little silly since 'perspective' doesn't require
atomicity (rather, it adds an additional transformation to any 3-D
descendants, which already require atomicity), the spec requires it, and
it matches WebKit.
Now that the first patch in this bug changed things so that 'none' is
reliably stored as eStyleUnit_None (rather than being stored as a 0
length when it comes from the initial value), we know mChildPerspective
is always > 0 when it is eStyleUnit_Coord, and there's no point making
the additional check.
Prior to this patch, we failed to honor:
* margin-left on elements in inline layout with 0 width and 0 height
* margin-right on elements in inline layout with 0 width
I think that was because the code in CanPlaceFrame to discard both
margins when the width was 0 was running after the left-margin was
applied, unless the later code in PlaceFrame (checking both width 0 and
height 0) un-applied that left margin.
The assertion count change in test_value_computation.html is due to 2
additional "bad width" assertions (I presume from honoring large
margins that were previously ignored).
The change to 538935-1-ref.html is to match an improvement in rendering
of the margins in the test, where both sides of the margin are now
honored.
The change to layout/reftests/text-overflow/marker-basic-ref.html is to
keep the reference (which uses margins) rendering the same way following
the changes to margin handling.
The new behavior (in the reftests added in layout/reftests/inline/)
matches at least Chromium; I didn't check any other browsers.
At the same time, move the handling of outlines on inlines that contain
blocks earlier, so that we factor it into the stored frame property (and
thus have the stored frame property) and so that we include it
accurately in the overflow calculation.
At the same time, move the handling of outlines on inlines that contain
blocks earlier, so that we factor it into the stored frame property (and
thus have the stored frame property) and so that we include it
accurately in the overflow calculation.
The purpose of this change is to make the code less confusing (since it's not clear to me why one would check HasTransform here), and in general to reduce the number of callers of HasTransform, since HasTransform is a complicated check that checks too many things and probably isn't the right thing for many of its callers (see, e.g., bug 968555).
This is pure refactoring because:
(1) We're calling HasTransform only if mTransformStyle is
NS_STYLE_TRANSFORM_STYLE_PRESERVE_3D.
(2) HasTransform can return false for either of two reasons:
(a) because HasTransformStyle is false, which cannot be the case
here because HasTransformStyle checks mTransformStyle, and we
already know that check passes because of (1)
(b) because IsFrameOfType(nsIFrame::eSupportsCSSTransforms) is
false.
This means that we can replace the HasTransform check with solely the
IsFrameOfType check.
