Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID:20180228100110 [Affected versions]: Nightly 60.0a1 [Affected platforms]: Windows 10 x64 [Steps to reproduce]: 1.Launch Nightly 60.0a1 with a new profile 2.Go to about:preferences#privacy and check "Block cookies and site data" radio 3.Add http://mdn.github.io/to-do-notifications/index.html to the Exceptions list with Allow for Session status 4.Go to http://mdn.github.io/to-do-notifications/index.html page and fill the boxes to add a new to do task 5.Restart Firefox and go to Settings panel 6.Go to http://mdn.github.io/to-do-notifications/index.html [Expected result]: STEP 5.The website from step 4 should not be displayed in Settings panel STEP 6.The task added in step 4 should not be displayed. [Actual result]: The task added in step 4 is displayed. The website from step 4 is not removed from Settings panel

It sounds like Allow for Session is broken. roxana, can you find when this regressed using mozregression?

Last good revision: c7ffbaaf8c2e3ac13577da6413aa14fcf73ee151 First bad revision: 36be9b83bcc9928cd06ebdd3402939e152582fff Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c7ffbaaf8c2e3ac13577da6413aa14fcf73ee151&tochange=36be9b83bcc9928cd06ebdd3402939e152582fff

I don't think bug 1432743 changed this, it just moved around the UI. Andrew, what's the currently expected behavior for indexedDB when you have a cookie exception for a certain site set to "Allow for Session"? (This might or might not be related to bug 1400678?)

:janv all yours.

IndexedDB is currently allowed in session-only mode. See https://bugzilla.mozilla.org/show_bug.cgi?id=1413615#c7 and the following comment for the brief investigation that concludes not a lot of thought was put into the original decision and it's never changed. Bug 1400678 will fix that, but in the short term we could move the storage checks for IDB and workers (that powers the IDB decision on workers) to be based on comparison versus eAllow versus eDeny.

(In reply to roxana.leitan@softvision.ro from comment #2) > Last good revision: c7ffbaaf8c2e3ac13577da6413aa14fcf73ee151 > First bad revision: 36be9b83bcc9928cd06ebdd3402939e152582fff > > Pushlog: > https://hg.mozilla.org/integration/autoland/ > pushloghtml?fromchange=c7ffbaaf8c2e3ac13577da6413aa14fcf73ee151&tochange=36be > 9b83bcc9928cd06ebdd3402939e152582fff I can reproduce this behavior in beta and release (which makes sense given that we did not change this code so far), the above regression range simply shows when the UI was moved around. I don't think this is a regression. I think we could keep this open to either track bug 1400678 or go with the short term solution, depending on how urgent we consider this issue. I'm currently leaning towards just waiting on bug 1400678 to fix it. Let's decide in triage.

Why was this made a P1? :johannh?

Apologies, we had it in our triage list and I think that was just an unintended side effect of my other change. I reverted it :)

Bug 1400678 has been fixed, can we close this now ?

Yes, duping to that bug for clarity.