On Wed, Jan 23, 2019 at 11:33 AM Andrea Marchesini <amarches...@mozilla.com> wrote:
> > You pointed out one case of unpredictable behaviour: a website's logic >> cannot preserve assumptions across the entire duration of it's JS >> execution >> context. But if we don't apply the policy instantly, isn't the reverse >> situation also possible? > > > With my proposal, you will have 2 tabs, loading the same origin with 2 > different cookie behaviors. > Let's assume that one is BEHAVIOR_ACCEPT and the other one > BEHAVIOR_REJECT, doesn't matter the order. > The 2 tabs will not be able to communicate to each other because: > > - we don't dispatch storage events, and/or they will not considered by the > other tab. > - sessionStorage, localStorage, indexedDB, ... let's say storage APIs > throw exceptions in the tab with BEHAVIOR_REJECT policy. > - that tab will not be able to use APIs such as SharedWorkers, or > BroadcastChannels. > > In general, we allow tab communication only if they have both > BEHAVIOR_ACCEPT cookie policy (or the corresponding permission: > ACCEPT_ALLOW). > > Note that what I'm describing here already exists for private browsing > contexts which are unable to talk with same origins in normal contexts. > Ah -- this private browsing analogy clarifies some things for me. For PB we make private tabs be in a different window. I don't know of that's a choice or a technical limitation. If it's a choice, should we be separating tabs with different cookie behaviours in some way? If we're concerned about this being confusing (like private tabs mixed with non-private), can we force existing tabs to close or reload right then so there's never this dual state you're working to change? Best, Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
