Establish display item fragment scope for atomic inlines.

We already did this when painting text items and inline box items (non-atomic inlines), but we also need to do it when painting atomic inlines.

Although it's rather unusual for an atomic inline LayoutObject to be associated with multiple fragment items, it may happen if an atomic inline is associated with a text-overflow ellipsis (that's a fragment item of type kGeneratedText).

A text-overflow ellipsis fragment item is associated with the last LayoutObject that fits before the ellipsis, and if this happens to be an atomic inline (e.g. an image), it will be that one.

To explain what went wrong in the test included: There's a SPAN with two lines inside. Two fragment items are created for the SPAN. The item on the first line gets fragment ID 0, and the one one the second line gets ID 1. On the second line there's an image followed by something that gets clipped by overflow, and there will be a text-overflow ellipsis. The image is the last (and only, actually) object that fits, so the ellipsis gets associated with that object. Two fragment items are created for the image object, first the image itself, and then the ellipsis. They get a fragment ID of 0 and 1, respectively.

When painting the SPAN on the second line, we establish a fragment item scope for it, and the ID is 1. When we paint the actual image, we didn't establish a scope, so that ID 1 was used for the image as well (even though its fragment ID is 0). When painting the ellipsis afterwards, we establish a scope, with ID 1. Because of this we got the same display item client (from the layout object) painted twice with the same fragment ID.

Bug: 41493875 Change-Id: I5fc87fc086ecd3c4367dca7c3ad94c22c031f7f7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5272607 Commit-Queue: Morten Stenshorne mstensho@chromium.org Reviewed-by: Koji Ishii kojii@chromium.org Cr-Commit-Position: refs/heads/main@{#1257896}