Closed Bug 1379654 Opened 2 years ago Closed 2 years ago

navigator.storage.persisted() returns "true" after the "persistent storage" permission is cleared from Control Center

Categories

(Core :: DOM: Core & HTML, defect)

56 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: icrisan, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [storage-v1])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170710092636

CASE 1: Default window

Steps to reproduce:
1. Launch Nightly 56.0a1
2. Open an url and persist it
3. From the "Control Center" clear the "persistent storage" permission
4. Refresh the page
5. Check the returned value by the persisted API


CASE 2: Private window

Steps to reproduce:
1. Launch Nightly 56.0a1
2. Open an url and persist it  
3. Open the url from step 2 in a private window 
4. From the private window, "Control Center" section, clear the "persistent storage" permission
5. Refresh the page from the private window and from the default window
6. Check the returned value by the persisted API from the default window


Expected results:
The value returned is "false".

Actual results:
The value returned is "true".


NOTE: Issue does not reproduces if the "persistent storage" permission is removed from Preferences-> Privacy & Security-> Site Data
Please see the recorded video for this issue: https://drive.google.com/file/d/0B_L6mNdlzO5TU0VidmhsMUpGRU0/view.
Also I'm not sure if it's ok to be able to clear the "persistent storage" permission from a private window("Control Center" or "Preferences") since from a private window sites cannot be persisted. Please confirm the expected behavior.
The video from comment 1 is not ok. Please try this one: https://drive.google.com/file/d/0B_L6mNdlzO5TMUQ1UTBJUVNGZE0/view
Franics,
This bug we've discussed in all hands meetings with Roxana and you. We need UX to comment the preferred behavior for "Case 2". Right now, removing persistent permission using permission manager won't also remove persisted storage. Permission manager doesn't know anything about persisted storage, it only handles permission.


For case 1, as we all agree that in the storage meeting previously, in bug 1348223 we have conclusion:

"Currently we expose site data under permissions (the persistent storage permission), but this does not make much sense, as clearing the permission doesn't actually change the abilities of the site in question. It will still have persistent data and the data won't be gone.

So instead we should not expose site data under permissions, but have it under security where we also place cookies. We just need one option there:
  Site Data [Remove]
(This same criticism applies to the "Show site information" dialog. Ideally we fix both at the same time.)"


For case 2, can UX clarify the UX specification for private browsing window?
Flags: needinfo?(frlee)
hi Mark,

could you please comment on the case 2 mentioned in the comment3 ?

thank you very much
Flags: needinfo?(frlee) → needinfo?(mliang)
(In reply to Ioana Crisan from comment #1)
> Please see the recorded video for this issue:
> https://drive.google.com/file/d/0B_L6mNdlzO5TU0VidmhsMUpGRU0/view.
> Also I'm not sure if it's ok to be able to clear the "persistent storage"
> permission from a private window("Control Center" or "Preferences") since
> from a private window sites cannot be persisted. Please confirm the expected
> behavior.

You can't persist in private browsing window. We fallback persist() to persisted() in private window because persist in private browsing window doesn't make sense from the privacy point of view.
(In reply to Ioana Crisan from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101
> Firefox/56.0
> Build ID: 20170710092636
> CASE 2: Private window
> 
> Steps to reproduce:
> 1. Launch Nightly 56.0a1
> 2. Open an url and persist it  
> 3. Open the url from step 2 in a private window 
> 4. From the private window, "Control Center" section, clear the "persistent
> storage" permission
Like case 1 what I mentioned, to clear "persistent storage" permission in Comment 3, it doesn't also clear site data storage space at the same time.

> 5. Refresh the page from the private window and from the default window
> 6. Check the returned value by the persisted API from the default window
Since it doesn't clear storage space at Step 4, promise resolved true is expected.
> 
> Expected results:
> The value returned is "false".
> 
> Actual results:
> The value returned is "true".
> 
> 
> NOTE: Issue does not reproduces if the "persistent storage" permission is
> removed from Preferences-> Privacy & Security-> Site Data
Yes. This will explicitly clear both permission and storage space.
hi Mark,

could you please comment on this?

thank you very much
(In reply to Francis Lee [:frlee] from comment #7)
> hi Mark,
> 
> could you please comment on this?
> 
> thank you very much


For case 2, I'd say ideally a website's permission status in each private browsing session is isolated and is inherited from the normal browsing session. That means, clearing a website's permission in private window X won't affect the permission status in private window Y and all the other normal windows.
Flags: needinfo?(mliang)
NI myself, we will triage this in the Storage project meeting.
Flags: needinfo?(htsai)
[Triage] 

Case I is a known issue tracked in bug 1348223, that is put in our backlog (P3).
Case II - per UX comment in comment 10, the actual behaviour SV reported is as our UX expected. So this part is invalid.

Let's use bug 1348223 track case I, and I am going to close this as invalid to reflect case II. Thanks.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(htsai)
Resolution: --- → INVALID
Whiteboard: [storage-v1][triage] → [storage-v1]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.