Closed
Bug 1379654
Opened 7 years ago
Closed 7 years ago
navigator.storage.persisted() returns "true" after the "persistent storage" permission is cleared from Control Center
Categories
(Core :: DOM: Core & HTML, defect)
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
Reporter | ||
Comment 1•7 years ago
|
||
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.
Reporter | ||
Comment 2•7 years ago
|
||
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)
Comment 4•7 years ago
|
||
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.
Comment 7•7 years ago
|
||
hi Mark,
could you please comment on this?
thank you very much
Comment 8•7 years ago
|
||
(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)
Comment 9•7 years ago
|
||
NI myself, we will triage this in the Storage project meeting.
Flags: needinfo?(htsai)
Comment 10•7 years ago
|
||
[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: 7 years ago
Flags: needinfo?(htsai)
Resolution: --- → INVALID
Whiteboard: [storage-v1][triage] → [storage-v1]
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•