commit 9b8c24841805d0bf85f17899303b3a3d3e7509fa
author zhoupeng <zhoupeng.1996@bytedance.com> Wed Sep 25 21:49:35 2024
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed Sep 25 21:49:35 2024
tree 6dc62bd169e46091ea6f920eccc71d79313a3bda
parent 8d41c1e23ddba6bc91096e7cc07424f0bbe8b6a3

The <embed> element does not have to enforce layout when the type attribute is set to image

According to the spec[1], the `<embed>` element represents nothing
in those conditions:
> The element has neither a src attribute nor a type attribute.
> The element has a media element ancestor.
> The element has an ancestor object element that is not showing
> its fallback content.
There is no requirement for `ImageType` to enforce layout in the spec.
So removed the logic of forcing layout when `type` is set to `image`.

This patch also moves "embed-represent-nothing-04.html" to
"embed-in-object-fallback-image.html".
And "embed-represent-nothing-04.html is failing in all browsers.
According to the spec[2]:
> If the data attribute is present and its value is not the empty
> string, then: ...
> Fallback: The object element represents the element's children.
> This is the element's fallback content.
If the `object` element does not have a `data` attribute,
its children should be used as fallback content.
The test case in "embed-represent-nothing-04.html", `object` does not
have a `data` attribute, so it should fallback, show it's children.

[1]: https://html.spec.whatwg.org/multipage/#the-embed-element
[2]: https://html.spec.whatwg.org/multipage/#the-object-element

Bug: 40780999
Change-Id: I86bcd3cfe68c3cbe882c02008770bd3330a56026
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5877938
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Peng Zhou <zhoupeng.1996@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#1360197}