User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3775.0 Safari/537.36 Edg/76.0.144.0

Steps to reproduce:

Navigate to https://debugtheweb.com/echoformatted.aspx
Click the "Clear Site Data..." link at the bottom.

Actual results:

Observe: Page refreshes; there's no visible navigation to the target ClearSiteData.aspx page.

Expected results:

The target url should be the top-level URL (and, of course, the storage should be cleared).

I think what's happened here is that Firefox sees "Clear-Site-Data: "*"" and knows that it's supposed to reset any execution contexts for the origin. However, because this happens during the processing of the response headers for the new page, it refreshes the current page, effectively aborting the navigation to the target page.

This problem does not reproduce in Chrome.

Chrome doesn't support executionContexts.
Annevk, reading the spec, I don't see why the current page should not be reloaded. Could it be a spec bug?

Re #1: Agree that the spec probably should explicitly say what to do.

My expectation is that as soon as the HTTP/200 headers of the new page have been read, the old page's execution context shouldn't exist anymore because a new page is being committed. (You have to wait for the headers because if they're HTTP/204, then no new page is committed). There's probably a newer spec than https://www.w3.org/TR/2010/WD-html5-20101019/history.html#navigating-across-documents

It would make sense to me that browsing contexts displaying a document of the affected origin which are also currently being navigated are not reloaded, but this might add quite a bit of complexity in an already underspecified landscape (part of my objection to Google's approach of bolting things on top of underspecified/undertested architectures and calling it progress). What if the Clear-Site-Data header appeared on a redirect that goes toward another redirect that goes to a mailto URL? In that case the displayed document would not end up being replaced and should be reloaded, I suppose?

I think we should drop support for the executionContexts feature at this point given that Google has still not added it or taken the time to answer our questions around it and we don't have time to figure out all these details on our own.

I think we should drop support for the executionContexts feature at this point given that Google has still not added it or taken the time to answer our questions around it and we don't have time to figure out all these details on our own.

It seems reasonable to me, but I would like to see this issue discussed at a spec level. Before removing this feature, I would like to see it removed from the spec. Do you think is this possible?

Part of my setup in comment 3 does not work as we only allow executionContexts for 2xx replies, but that'd still give the 204 scenario as potentially problematic.

I filed https://github.com/w3c/webappsec-clear-site-data/issues/59 to remove executionContexts, but as I mentioned prior issues we filed have also not been addressed so I don't think we should wait for it to actually be removed from the specification before proceeding here.

https://hg.mozilla.org/mozilla-central/rev/071e3e715638

Documentation updates:

• Submitted BCD PR 4372 adding entries into the database for each directive, with executionContexts noted as being removed in Firefox 68
• Updated Firefox 68 for developers