Devtools provides a better access:
1. press F12 or rightclick the page and click "Inspect"
2. switch to "Applications" panel (if it's not visible click the ... button and find it in "More tools")
3. click "Clear storage" on the left
4. click "Clear site data" button at the bottom of the panel

However, I agree, both methods are extremely unfriendly UX-wise.

baudav@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.12.6 on the latest Canary 67.0.3368.0 and Stable 65.0.3325.146 by following the below steps.

1. Launched Chrome and navigated to few websites.
2. Couldn't observe any file Mega.nz in chrome://settings/content/cookies.

Request you to provide the website where this mega.nz file can be added to cookies for further triaging of the issue.

Thanks..

Hi,

Data for Mega.nz is not the problem. Just hard with new UI setting to find data stored "File System" (first must know it's stored with cookies now; 15min to find that)
For Mega.nz, chrome store file in chrome profil when download file (C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\File System): you can test with this link: https://mega.nz/#!AhRTQTbS!07u5RiY3C-wJ38hjKsTNNUmcdqwtPAGRlLefJGdHcyM

screenshot after download file: https://i.imgur.com/u1E7DVk.png  469MB used in Chrome profil and never removed: https://i.imgur.com/S6XCRyo.png


1/problem with filter search? same as screencast after return on the very long cookies and data list, filter not work with previous entry, must edit filter search.
 **what is expected: the filter remains active and the same

2/refresh page chrome://settings/cookies/detail?site=mega.nz not refresh value, must return in list and open selection another time (but must edit filter because not work).
 what is expected: refresh page = refresh value

@woxxom: devtools not report this filesystem usage: https://i.imgur.com/8Ypzx39.png

3/perhaps chrome://settings/clearBrowserData must clear this and display size used in FileSystem folder (and not with cookies) ?

I not know impact if remove folder \File System in chrome profil (easy clean); and not know impact if remove this data for other website (for Mega.nz no problem to remove it; after download and save file it's not used by mega)
sorry for my english and my lack of information

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

baudav@ Thanks for the feedback.

Tested this issue on Windows 10 on the reported version 65.0.3325.88 and latest Canary 67.0.3368.1 as per comment #4.

1. Launched Chrome and navigated to the website https://mega.nz/#!AhRTQTbS!07u5RiY3C-wJ38hjKsTNNUmcdqwtPAGRlLefJGdHcyM
2. Downloaded the file of 469 MB and placed this file in the system path C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\File System.
3. Navigated to chrome://settings/siteData and in search text field searched for mega, could see one entry of mega.nz file.
4. On expanding the File System option, can see the Persistent storage value as None.
5. On hitting the back button, can see that the whole list of cookies is seen and changing the search value again shows the mega.nz file.

Attached is the screen cast for reference.

Request you to please check and update if anything is missed from our end in triaging the issue.

Also please help us with the exact expected behavior which will help in further triaging of the issue.

Thanks..

Deleted: 820816-1.mp4 1.9 MB

	820816-1.mp4 1.9 MB View Download

hi,
not store the file in FileSystem folder. Just download it. Chrome request to autorize mega to store data, accept (https://i.imgur.com/gbOHTAn.png). When download is complete (in webpage animation https://i.imgur.com/v1l63z2.png) it request to save (or save without request), save it in default download folder. At this time you can see in FileSystem (https://i.imgur.com/1VaX362.png)

I tested again in new PC installation (without antivirus and W10), FileSystem folder is clean after remove all data by chrome://settings/clearBrowserData. it just misses the size that is not specified. =>I must check my antivirus/extensions, perhaps it block chrome to remove file. problem in my side! sorry

But I see in your screencast the same problem with the search filter. When return, you must edit search (remove one letter, add it) to re-apply filter. Else it display full list, but filter search box say 'mega'. (by design ? )

One filter to just display FileSystem data,local data (without cookies)?  to clean only FileSystem not useful (ex:mega.nz and other but hard to find it.. but not remove all (not remove cookies and other data used for example by google drive,calendar...).

And very hard: now must open settings, and content and cookies and display cookies/data.. and can't see data size used; must open each category to see size of data.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

baudav@ Thanks for the feedback.

As per comment #7, we understand that the File system problem was caused due to antivirus/extensions and it is solved now after clearing all the data in chrome://settings/clearBrowserData.

Can you please confirm if this is the issue you are seeing.
- While searching for Mega.nz in chrome://settings/siteData, can see one entry in the Cookies list. On hitting the back arrow, can see that the whole list of cookies is seen and changing the search value again shows the mega.nz file.

Also please confirm if below (1) & (2) are new feature requests you are expecting.
1) One filter to just display FileSystem data,local data (without cookies)?  to clean only FileSystem not useful (ex:mega.nz and other but hard to find it.. but not remove all (not remove cookies and other data used for example by google drive,calendar...).
2) And very hard: now must open settings, and content and cookies and display cookies/data.. and can't see data size used; must open each category to see size of data.


Thanks..

Hi,
yes this is the issue: on hitting the back arrow, I see the search field displaying mega; but all the list is displayed without filter. (for each return on the list, it is necessary to re-modify the filter) 

and (1) & (2) is new feature requests (regression since new settings UI design)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

baudav@ Thanks for the feedback.

Tested this issue on Mac OS 10.12.6, Windows 10 and Ubuntu 14.04 on the latest Canary 67.0.3370.0 and Stable 65.0.3325.162 and able to reproduce as per comment #10.

Bisect Information:
===================
Good Build: 63.0.3238.0 (Revision - 508208)
Bad Build : 63.0.3239.0 (Revision - 508578)

On executing the per-revision bisect script, below is the Changelog URL:

https://chromium.googlesource.com/chromium/src/+log/4cdc761ecbeb58ad52db6667c9f505af9dd0bed3..7bd49763ba4347be4b631a6443346f3ac1dcdb24

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/714241

dschuyler@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.
Request you to also check the feature requests mentioned in comment #7 and help further. 

Thanks.

Created crbug.com/822389 and crbug.com/822393 to track the enhancements.

Keeping this bug to only track the issue of not (re-)applying the filter when coming back to the list using the back arrow. Changing bug title (summary) to reflect this focused role.

CL at https://chromium-review.googlesource.com/c/chromium/src/+/964986

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c551613c10ae4b974465ee58f9b690c1cbab12d

commit 2c551613c10ae4b974465ee58f9b690c1cbab12d
Author: Dave Schuyler <dschuyler@chromium.org>
Date: Thu Mar 15 23:56:00 2018

[MD settings] fix filter on return from sub-page

This CL resets the filter_ member in the site data handler (c++) so that
the filter will be reapplied when revisiting the page.

Bug:  820816 
Change-Id: Id710d8f6b9ec35f8ee69088dbbd8d8d9b3691c38
Reviewed-on: https://chromium-review.googlesource.com/964986
Reviewed-by: Tommy Li <tommycli@chromium.org>
Commit-Queue: Dave Schuyler <dschuyler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543555}
[modify] https://crrev.com/2c551613c10ae4b974465ee58f9b690c1cbab12d/chrome/browser/ui/webui/settings/settings_cookies_view_handler.cc

Able to reproduce this issue on reported version 65.0.3325.88. Hence verifying the fix on latest canary 67.0.3372.0 using Mac 10.13.3, Ubuntu 14.04 and Windows 10.

Observing only filtered result on returning from subpage. Attaching screencast for reference. Hence adding TE-Verified labels.

Thanks!

Deleted: 820816_ 67.0.3372.0.mp4 1.1 MB

	820816_ 67.0.3372.0.mp4 1.1 MB View Download