Re: [manifest] Allow multiple application contexts per app (#294)

@benfrancis wrote: 
> the Chrome Web Store might be a good place to look for existing use cases.

So, [looking at why Chrome apps seem to need this](https://github.com/search?utf8=%E2%9C%93&q=%22chrome.app.window.create%22&type=Code&ref=searchresults
)... it appears that they are used by background and event pages (`background.js`, etc.):

Because js-based background and event pages have no DOM or representation, it makes sense to sometimes pop-up a window to allow the user to do something (using HTML). 

If we were to make some kind of analogy, I guess we could view a background/event page as a service worker. If that is the case, then the service worker may be able to create new browsing contexts of some type and in some way (independently of whatever the manifest spec says) - like, an auxiliary browsing context created with `window.open()`. As chrome's background.js things don't have a DOM, they don't have `window.open` and hence can't rely on it. It will probably be the same case with Service Workers - but that's best taken up with the service worker folks. 

Further, [Chrome's documentation](https://developer.chrome.com/apps/app_lifecycle#create_windows) states that: "By default, these windows are created with a script connection to the event page and are directly scriptable by the event page." Which implies some kind of parent-child relationship (not a new independent application context). 

I propose we close this until we see what all the limitations are with just using `window.open`. Then we can reopen once we have some concrete use cases and demand from developers (that can't be addressed in a sane way with `window.open`). 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/294#issuecomment-69138738