Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load events across portals #26

Open
lucasgadani opened this issue Nov 1, 2018 · 10 comments
Open

Load events across portals #26

lucasgadani opened this issue Nov 1, 2018 · 10 comments
Labels
design work needed An acknowledged gap in the proposal that needs design work to resolve spec todo A nitty-gritty detail that needs spec work

Comments

@lucasgadani
Copy link
Collaborator

We need a way to synchronize events between the embedder and the portal. This could be done with a load event on the portal element that notifies the embedder that the portal has completed loading.

@lucasgadani
Copy link
Collaborator Author

We should also think about whether the portal element should delay the load event of its containing document.

The spec mentions that <iframe>s should delay the load event until they are ready for post-load tasks (https://html.spec.whatwg.org/#the-iframe-element:delay-the-load-event).

@domenic
Copy link
Collaborator

domenic commented May 8, 2020

Have any recent course corrections changed our decision here, or do we still think a load event is valuable? I'd be inclined to imitate iframes, in general.

@domenic domenic added the spec todo A nitty-gritty detail that needs spec work label May 8, 2020
@jeremyroman
Copy link
Collaborator

The Chromium implementation does have a load event (analogous to iframes) which we found to be very useful for writing tests. I think we probably should have this, and therefore should spec it.

@domenic
Copy link
Collaborator

domenic commented May 11, 2020

Is it OK to communicate cross-origin load?

@jeremyroman
Copy link
Collaborator

We do for iframes. And I think #191 makes a compelling point that it's difficult to hold properly without some basic signals about the readiness of the content.

@jakearchibald
Copy link
Collaborator

We do for iframes.

Although iframes wouldn't be first-party, and portals might be. Providing the load event of a first-party page would be a new capability that we should probably avoid.

@jeremyroman
Copy link
Collaborator

Fair point. Popups probably still do as well, but maybe given the direction frames are going we should either not fire this, or restrict it to same-origin.

We'd previously found it rather inconvenient to know when you could start talking to a portal contents via postMessage (plumbing your own ready message works but gets old quickly, and it's also kinda nice to be able to delay the outer load). But those concerns apply more acutely to portals with which you are permitted to coordinate, so maybe this should be re-evaluated.

@domenic
Copy link
Collaborator

domenic commented May 20, 2020

Adding "design work needed" since it sounds like we're not sure whether this should be fired for cross-origin portals...

I guess I can still work on a spec PR though that fires it at all times, and we could restrict it later.

@domenic domenic added the design work needed An acknowledged gap in the proposal that needs design work to resolve label May 20, 2020
domenic added a commit that referenced this issue May 20, 2020
domenic added a commit that referenced this issue May 20, 2020
@domenic
Copy link
Collaborator

domenic commented May 20, 2020

I put up a draft for firing the load event.

How do we feel about delaying the load event of the outer document? I'm not sure what the load event is used for these days, so it's hard to say whether it's worth the complexity... I guess I use it when writing tests sometimes.

@jeremyroman
Copy link
Collaborator

I don't feel strongly, but if I were an author I think I would expect it to behave similarly to images, frames, etc.

domenic added a commit that referenced this issue May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design work needed An acknowledged gap in the proposal that needs design work to resolve spec todo A nitty-gritty detail that needs spec work
Projects
None yet
Development

No branches or pull requests

4 participants