Bugzilla

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)
> This seems pretty expected. We don't and never have bothered making css prefs be part of the cache key or so.

It might be expected at a technical level, given the knowledge that this stylesheet happens to be cached; but it feels like a footgun that's worth avoiding if we can arrange to purge the cache, no?

For "live" prefs (those that don't explicitly require a browser restart) for web platform features, I think typically we've always been able to toggle the pref and then reload a testcase, and reasonably expect to see that the pref-flip has taken effect.  It's a bit odd that some CSS features might be in an in-between phase where simply reloading isn't sufficient.

> You can clear site data to get the pref to apply afaict.

Confirmed, that seems to fix it (click lock icon, clear cookies & site data).  That seems a bit heavyweight though, since that purges login state etc.  Intuitively it feels like a reload or shift+reload should work here (even if there are technical reasons why they don't).

It feels like perhaps the shared-stylesheet-cache should register an observer to listen for changes to the `layout.css.*` suite of about:config prefs, similar to what we do for the Shared Script Cache here:
https://searchfox.org/firefox-main/rev/9ffc661a59959bcfdd1ac91119739ac76b778ee7/dom/script/SharedScriptCache.cpp#101,109-112
```cpp
void SharedScriptCache::Init() {
...
  nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
  if (prefs) {
    prefs->AddObserver("urlclassifier", this, false);
    prefs->AddObserver("privacy.trackingprotection.enabled", this, false);
```
https://searchfox.org/firefox-main/rev/9ffc661a59959bcfdd1ac91119739ac76b778ee7/dom/script/SharedScriptCache.cpp#132-136
```cpp
NS_IMETHODIMP
SharedScriptCache::Observe(nsISupports* aSubject, const char* aTopic,
                           const char16_t* aData) {
  if (strcmp(aTopic, NS_PREFBRANCH_PREFCHANGE_TOPIC_ID) == 0) {
    SharedScriptCache::Clear();
```

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)
> This seems pretty expected. We don't and never have bothered making css prefs be part of the cache key or so.

It might be expected at a technical level, given the knowledge that this stylesheet happens to be cached; but it feels like a footgun that's worth avoiding if we can arrange to purge the cache, no?

For "live" prefs (those that don't explicitly require a browser restart) for web platform features, I think typically we've always been able to toggle the pref and then reload a testcase, and reasonably expect to see that the pref-flip has taken effect.  It's a bit odd that some CSS features might be in an in-between phase where simply reloading isn't sufficient (but closing-and-reopening the tab might be).

> You can clear site data to get the pref to apply afaict.

Confirmed, that seems to fix it (click lock icon, clear cookies & site data).  That seems a bit heavyweight though, since that purges login state etc.  Intuitively it feels like a reload or shift+reload should work here (even if there are technical reasons why they don't).

It feels like perhaps the shared-stylesheet-cache should register an observer to listen for changes to the `layout.css.*` suite of about:config prefs, similar to what we do for the Shared Script Cache here:
https://searchfox.org/firefox-main/rev/9ffc661a59959bcfdd1ac91119739ac76b778ee7/dom/script/SharedScriptCache.cpp#101,109-112
```cpp
void SharedScriptCache::Init() {
...
  nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
  if (prefs) {
    prefs->AddObserver("urlclassifier", this, false);
    prefs->AddObserver("privacy.trackingprotection.enabled", this, false);
```
https://searchfox.org/firefox-main/rev/9ffc661a59959bcfdd1ac91119739ac76b778ee7/dom/script/SharedScriptCache.cpp#132-136
```cpp
NS_IMETHODIMP
SharedScriptCache::Observe(nsISupports* aSubject, const char* aTopic,
                           const char16_t* aData) {
  if (strcmp(aTopic, NS_PREFBRANCH_PREFCHANGE_TOPIC_ID) == 0) {
    SharedScriptCache::Clear();
```

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)
> This seems pretty expected. We don't and never have bothered making css prefs be part of the cache key or so.

It might be expected at a technical level, given the knowledge that this stylesheet happens to be cached; but it feels like a footgun that's worth avoiding if we can arrange to purge the cache, no?

For "live" prefs (those that don't explicitly require a browser restart) for web platform features, I think typically we've always been able to toggle the pref and then reload a testcase, and reasonably expect to see that the pref-flip has taken effect.  It's a bit odd that some CSS features might be in an in-between phase where simply reloading isn't sufficient (but closing-and-reopening the tab might be).

> You can clear site data to get the pref to apply afaict.

Confirmed, that seems to fix it (click lock icon, clear cookies & site data).  That seems a bit heavyweight though, since that purges login state etc, so it makes it harder to quickly e.g. see how Facebook or Instagram etc. renders with/without a particular feature enabled.  Intuitively it feels like a reload or shift+reload should work here (even if there are technical reasons why they don't).

It feels like perhaps the shared-stylesheet-cache should register an observer to listen for changes to the `layout.css.*` suite of about:config prefs, similar to what we do for the Shared Script Cache here:
https://searchfox.org/firefox-main/rev/9ffc661a59959bcfdd1ac91119739ac76b778ee7/dom/script/SharedScriptCache.cpp#101,109-112
```cpp
void SharedScriptCache::Init() {
...
  nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
  if (prefs) {
    prefs->AddObserver("urlclassifier", this, false);
    prefs->AddObserver("privacy.trackingprotection.enabled", this, false);
```
https://searchfox.org/firefox-main/rev/9ffc661a59959bcfdd1ac91119739ac76b778ee7/dom/script/SharedScriptCache.cpp#132-136
```cpp
NS_IMETHODIMP
SharedScriptCache::Observe(nsISupports* aSubject, const char* aTopic,
                           const char16_t* aData) {
  if (strcmp(aTopic, NS_PREFBRANCH_PREFCHANGE_TOPIC_ID) == 0) {
    SharedScriptCache::Clear();
```