[webcomponents] [Shadow]: Figure out how session history should work for <iframe>s in shadow DOM (bugzilla: 27325) (#184)

Title: [Shadow]: Figure out how session history should work for <iframe>s in shadow DOM (bugzilla: 27325)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325

----
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c0
*Olli Pettay* wrote on 2014-11-14 12:33:35 +0000.

Currently \<iframe\>s shouldn't be loaded at all in shadow DOM, but that
will probably change in bug 26365.

If some pages are then loaded to a shadow iframe, should the pages end up to
session history?
https://html.spec.whatwg.org/multipage/browsers.html#traverse-the-history-by-a-delta is the tricky part, and 
https://html.spec.whatwg.org/multipage/browsers.html#joint-session-history in particular.

----

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c1
*Dimitri Glazkov* wrote on 2014-11-14 15:49:50 +0000.

I would really like to have as little difference between an iframe in a shadow tree and a document tree as possible. For the developer, the shadow tree should walk and quack like a document tree :)

----

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c2
*Olli Pettay* wrote on 2014-11-14 16:09:08 +0000.

Well, integrating shadow \<iframe\>'s history to the rest of the page reveals 
information that there is an \<iframe\>. And especially if and when we get the proper information hiding, this will be an issue.

----

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c3
*Dimitri Glazkov* wrote on 2014-11-14 19:29:45 +0000.

(In reply to Olli Pettay from comment #2)
> Well, integrating shadow \<iframe\>'s history to the rest of the page reveals 
> information that there is an \<iframe\>. And especially if and when we get the
> proper information hiding, this will be an issue.

I see. Yes, this is applicable for the "closed/private" mode (bug 20144).

----

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c4
*Olli Pettay* wrote on 2014-11-15 15:59:46 +0000.

Not only to that, IMO. If we just randomly expose information about the shadow DOM to the outside world, what is the use of shadow DOM.

I consider this similar to https://code.google.com/p/chromium/issues/detail?id=394327 though less critical given that session history is rather
odd beast anyway.

----

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c5
*Olli Pettay* wrote on 2014-11-15 16:00:53 +0000.

Also, I think it is more important to have consistency within
shadow DOM, whether or not we're in closed/private mode, than consistency
with the normal DOM.

----

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325#c6
*Dimitri Glazkov* wrote on 2014-11-15 16:18:08 +0000.

(In reply to Olli Pettay from comment #4)
> Not only to that, IMO. If we just randomly expose information about the
> shadow DOM to the outside world, what is the use of shadow DOM.
> 
> I consider this similar to
> https://code.google.com/p/chromium/issues/detail?id=394327 though less
> critical given that session history is rather
> odd beast anyway.

I agree about the priority.

As for the use of shadow DOM, I would like for us to get on the same page. I tried to write the main goal here: https://gist.github.com/dglazkov/efd2deec54f65aa86f2e. This aligns closely with the thrust of the very early explorations of the problem: http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Layout_Manager

In this perspective, exposing information or making Shadow DOM presence detectable is not as big of a concern.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/184