-
Notifications
You must be signed in to change notification settings - Fork 40
Well defined environment for nested contexts of the receiving browsing context? #367
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
Comments
The behavior of |
CC @zhaobin2016 After internal discussion, we propose that Also the same restrictions on the top-level receiving browsing context should apply to nested contexts. |
This was addressed by PR #395 (which erroneously referred to a different issue). |
Addresses Issue #387: Well defined environment for nested contexts of the receiving browsing context
…with top level receiver frame When receiver page has sub frames, all frames will try to register receiver callbacks to OPM with the same presentation_id, triggering DCHECK failure. Also any frame reset will end offscreen presentation. According to w3c/presentation-api#367, only top level frame matters. This patch adds a is_main_frame_ flag to PresentationServiceImpl to indicate top level frame. BUG=734798 Review-Url: https://codereview.chromium.org/2949053002 Cr-Commit-Position: refs/heads/master@{#483436}
The Presentation API imposes a well-defined environment for the receiving browsing context when it is created, but it does not say anything about nested browsing contexts that this browsing context could create (e.g. with an
<iframe>
).I'm not clear how the restrictions on cookies, Application cache, Permissions, IndexedDB, Web Storage, and Service Workers propagate to nested browsing contexts in particular. Should the spec rather attach the steps that deal with these constraints to the create a browsing context algorithm in HTML so that they apply to all browsing contexts on the receiving side?
(This issue is unrelated to but still triggered by the discussion around
[SameObject]
and receiving browsing contexts in #365)The text was updated successfully, but these errors were encountered: