On Mon, Jan 28, 2019 at 10:51 AM Daniel Veditz <dved...@mozilla.com> wrote:
> On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini < > amarches...@mozilla.com> wrote: > >> If we try to apply the new cookie policy immediately, 3rd party trackers >> in opened tabs should switch to a first-party-isolation storage, but they >> could also have already data in memory (user-tokens), and populate the new >> cookie jar consequentially. This would break the isolation. The solution in >> this case, is to apply the change only after the reloading. >> > > That's a great point in favor of your proposal. I'm still concerned about > "infinite-page" sites (facebook/twitter/etc) where a user typically rarely > reloads. Would it be too ugly to apply an infobar to each active tab that > says "The cookie policy has changed. Reload to apply the new policy > [Reload]"? Or maybe has a [Reload this tab][Reload All] set of buttons. I > have serious misgivings about my UX suggestion here, but maybe it will > spark better ideas on how to communicate to users. An alert/doorhanger in > the pref page where the setting is changed that warns the user it only > applies to new pages and offers to reload all active tabs? > One option that we have for handling this change is to modify the way we apply the change in the Preferences UI instead of asking people to reload their pages. For example, we can ask the user to restart their browser when they make changes to the cookie policy/permissions (similar to how turning permanent private browsing on/off works), or add a notice in the Preferences saying that the changes made will only affect pages loaded from now on, etc. I don't think showing a message on every open tab to ask the user to reload it is the only UX that is possible for solving this problem, it's only one rough idea (AFAIK nobody has talked to the UX team about it yet!)... Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
