New issue
Advanced search Search tips

Issue 810012 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on:
issue 895511
issue 793935
issue 867831



Sign in to add a comment

GuestView container registration is racy

Project Member Reported by mcnee@chromium.org, Feb 7 2018

Issue description

Chrome Version: 66.0.3341.0

As observed in
 crbug.com/788914 
https://chromium-review.googlesource.com/c/chromium/src/+/857814
and
https://chromium-review.googlesource.com/c/chromium/src/+/905521
a guest view container may not have been registered by the time a caller tries to create one.

The registration is done in GuestViewContainer.registerElement where we have a readystatechange listener. There is currently a circular dependency ( crbug.com/793935 ) which prevents the registration from being done immediately, but other than that, it's not clear why the registration can't just be done immediately.
 

Comment 1 by mcnee@chromium.org, Feb 7 2018

Blockedon: 793935
Blockedon: 867831
Even after the circular dependency is fixed, it looks like we still can't register the element immediately.

At the time GuestViewContainer.registerElement is called, we may still be on about:blank. It looks like the custom element v0 registration context is document scoped and so the element could be registered for about:blank. Waiting for readystatechange before registering the element avoids this.

See https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/document_loader.cc?rcl=c4ba43ad875387fe19f41a2965724a3c77208899&l=1084

It looks like custom element v1 registration is scoped to the window instead of the document, so perhaps this won't be an issue once we migrate to v1 and then we wouldn't need the readystatechange anymore.
Blockedon: 895511

Sign in to add a comment