This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27325 - [Shadow]: Figure out how session history should work for <iframe>s in shadow DOM
Summary: [Shadow]: Figure out how session history should work for <iframe>s in shadow DOM
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 20144 26365
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-14 12:33 UTC by Olli Pettay
Modified: 2015-07-06 08:03 UTC (History)
3 users (show)

See Also:


Attachments

Description Olli Pettay 2014-11-14 12:33:35 UTC
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 Dimitri Glazkov 2014-11-14 15:49:50 UTC
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 Olli Pettay 2014-11-14 16:09:08 UTC
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 Dimitri Glazkov 2014-11-14 19:29:45 UTC
(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 Olli Pettay 2014-11-15 15:59:46 UTC
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 Olli Pettay 2014-11-15 16:00:53 UTC
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 Dimitri Glazkov 2014-11-15 16:18:08 UTC
(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.
Comment 7 Hayato Ito 2015-07-06 08:03:13 UTC
Moved to https://github.com/w3c/webcomponents/issues/184