I confirmed that the new test fails without the previous patch (since
the abspos element is 50px from the left edge of the viewport instead of
150px, and at the top edge instead of 100px from the top). The test
passes with the patch.
This changes nsDisplayImage::GetDestRect and nsImageFrame::PredictedDestRect to return
the true dest rect of the image, without intersecting it with the image content box.
The only caller of these functions that actually requires a rectangle that's within
the image's content bounds is nsDisplayImage::GetOpaqueRegion, so I'm changing that
to intersect with the display item's bounds.
I'm pretty sure nsImageFrame::MaybeDecodeForPredictedSize() also prefers the unclipped
dest rect, because it cares about the scale at which the image is painted, and not
about which parts of the image are painted.
Locally, these tests fail reliably for me without the patch. I'm not,
however, confident that they would continue to do so, across future
mutations in the code, were the bug to be reintroduced, given the amount
of fiddling I had to go through to get them to fail without the patch.
That is, without the patch:
table-row-opacity-dynamic-1.html shows the area of the row that's not
behind the text as a much more opaque blue than it should be (while
the area of the row that is behind the text is correct)
table-row-opacity-dynamic-2.html shows the area of the row that's not
behind the text as the white background showing through (while the
area of the row that is behind the text is correct)
Without the previous patches, the tests:
will-change-fixpos-cb-contain-1.html
will-change-fixpos-cb-filter-1.html
will-change-fixpos-cb-perspective-1.html
will-change-fixpos-cb-transform-style-1.html
fail, but they pass with the patches. The new tests:
will-change-fixpos-cb-height-1.html
will-change-fixpos-cb-transform-1.html
pass both ways: the first because it tests that nothing happens, and
the second because we were separately testing the will-change bit for
transform via HasTransform.
Locally, these tests fail reliably for me without the patch. I'm not,
however, confident that they would continue to do so, across future
mutations in the code, were the bug to be reintroduced, given the amount
of fiddling I had to go through to get them to fail without the patch.
That is, without the patch:
table-row-opacity-dynamic-1.html shows the area of the row that's not
behind the text as a much more opaque blue than it should be (while
the area of the row that is behind the text is correct)
table-row-opacity-dynamic-2.html shows the area of the row that's not
behind the text as the white background showing through (while the
area of the row that is behind the text is correct)
