New issue
Advanced search Search tips

Issue 890571 link

Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 853140
Owner:
Closed: Oct 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug


Participants' hotlists:
mine


Sign in to add a comment

ACID2 test fails (object scrollbars shown)

Reported by samir1...@gmail.com, Sep 29

Issue description

Chrome Version       : 69.0.3497.100
OS Version: 10.0
URLs (if applicable) : http://acid2.acidtests.org/#top
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
    Firefox: OK
    IE/Edge: OK

What steps will reproduce the problem?
1. Visit the URL http://acid2.acidtests.org/#top
2. See the face.

What is the expected result?
http://acid2.acidtests.org/reference.html

What happens instead of that?
There's an object with scrollbars instead of the eyes.


UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36



 
ACID2-Fail.jpg
13.9 KB View Download
Labels: Needs-Triage-M69
This issue also occurs on MacOS 10.13.6 in Version 69.0.3497.100 (Official Build) (64-bit) and Version 71.0.3564.0 (Official Build) canary (64-bit).
Components: Blink>HTML Internals>Sandbox>SiteIsolation
Status: Untriaged (was: Unconfirmed)
Summary: ACID2 test fails (object scrollbars shown) (was: ACID2 test fails)
This appears to be related to Site Isolation. Turning it off in Chrome://flags restores the rendering to what Edge/Firefox show (a red band for the eyes, no scrollbars).

https://www.webstandards.org/action/acid2/guide/index.html explains the test.

The eyes appear in the inner object element. The two ancestor object elements should both display their fallback contents — which is the inner object element. The fallback content of the inner object element should not be displayed as the data attribute returns a valid PNG image (depicting the eyes).

The object element points to a cross-origin (deliberate) 404.
Cc: kenrb@chromium.org creis@chromium.org wjmaclean@chromium.org dcheng@chromium.org
Add some relevant folks that can help look at what is happening. I wonder whether it works correctly if <iframe> is used instead of <object>, as there are some differences in behavior if I'm not mistaken.
Do we have to plumb a notification from DocumentLoader::LoadFailed() from a child frame to a parent frame in order for RenderFallbackContent() to be called on the object element?
It looks like this problem has a "TODO(dcheng): Implement." associated with it, landed 3.5 years ago: https://codereview.chromium.org/1125053002
Cc: ekaramad@chromium.org
Is this possibly a duplicate of  issue 853140 ?  +ekaramad@ who has a CL in progress for the latter issue.
Components: -Blink>HTML Blink>Scroll
Cc: bokan@chromium.org
Appears to be fixed 72.0.3590.0 for me. Can anyone confirm?
Mergedinto: 853140
Owner: ekaramad@chromium.org
Status: Duplicate (was: Untriaged)
Yes. I think this was a duplicate of another OOPIF object fallback. Marking as duplicate.

Sign in to add a comment