| Code-Review | +1 |
The long timeout looks worth a try, but let's remember to follow up to see if it helped. Most fetch web_tests run with a long timeout, many have some similar attributes to this test.
If the timeout does not help, it looks like we can split the test into two or maybe three separate tests.
I'm also curious how the test works. How does the renderer in blink get notified about the clear-site-data to clear its dom storage cache?
Here's the relevant test code:
```
// Test that Clear-Site-Data deletes the local storage in this partition.
const resp = await fetch(
"/storage/resources/clear-site-data.php", {method: "GET"});
assert_equals(resp.status, 200);
var totalTime = 0;
// 2 second timeout.
while ((localStorage.length != 0) && (totalTime < 2000)) {
await timePasses(50);
totalTime += 50;
}
assert_equals(localStorage.length, 0);
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The long timeout looks worth a try, but let's remember to follow up to see if it helped. Most fetch web_tests run with a long timeout, many have some similar attributes to this test.
If the timeout does not help, it looks like we can split the test into two or maybe three separate tests.
I'm also curious how the test works. How does the renderer in blink get notified about the clear-site-data to clear its dom storage cache?
Here's the relevant test code:
```
// Test that Clear-Site-Data deletes the local storage in this partition.
const resp = await fetch(
"/storage/resources/clear-site-data.php", {method: "GET"});
assert_equals(resp.status, 200);
var totalTime = 0;
// 2 second timeout.
while ((localStorage.length != 0) && (totalTime < 2000)) {
await timePasses(50);
totalTime += 50;
}
assert_equals(localStorage.length, 0);
```
Flagging this as unresolved.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Steve BeckerThe long timeout looks worth a try, but let's remember to follow up to see if it helped. Most fetch web_tests run with a long timeout, many have some similar attributes to this test.
If the timeout does not help, it looks like we can split the test into two or maybe three separate tests.
I'm also curious how the test works. How does the renderer in blink get notified about the clear-site-data to clear its dom storage cache?
Here's the relevant test code:
```
// Test that Clear-Site-Data deletes the local storage in this partition.
const resp = await fetch(
"/storage/resources/clear-site-data.php", {method: "GET"});
assert_equals(resp.status, 200);
var totalTime = 0;
// 2 second timeout.
while ((localStorage.length != 0) && (totalTime < 2000)) {
await timePasses(50);
totalTime += 50;
}
assert_equals(localStorage.length, 0);
```
Flagging this as unresolved.
Thank! I'll keep an eye on whether the long timeout helps.
For the renderer notification path, I traced it as:
`clear-site-data.php` sets `Clear-Site-Data: "storage"`.
`ClearSiteDataHandler::Run()` nparses that and calls `ExecuteClearingTask()`.
`ClearSiteDataHandler::ExecuteClearingTask()` calls `ClearSiteData()`.
`SiteDataClearer::RunAndDestroySelfWhenDone()` adds `BrowsingDataRemover::DATA_TYPE_DOM_STORAGE` for `ClearSiteDataType::kStorage`, then calls `RemoveWithFilterAndReply()`.
For an already-open localStorage area, this eventually reaches `LocalStorageImpl::DeleteStorage()`, which calls `StorageAreaImpl::DeleteAll()`.
`StorageAreaImpl::DeleteAll()` sends `AllDeleted()` to its registered `StorageAreaObserver`s.
Blink's `CachedStorageArea` is registered as a `StorageAreaObserver`, and `CachedStorageArea::AllDeleted()` clears the renderer-side cache.
So I think this test is waiting for that async deletion and observer callback to make it back to the frame.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |