1988195 - Flipping anchor positioning pref requires closing and reopening the tab

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[David Shin[:dshin]]

Attachment: Minimum Reproducible Case

STR:

1. Load test case
2. In about:config, flip the pref layout.css.anchor-positioning.enabled
3. Observe the test case
4. Close the tab for the test case
5. Reopen the test case

Expected: Pref flip should apply from step 3
Actual: Pref flip applies at step 5

mozregression points to https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=6fb1d0ccf4393763f55542c9acde2f85e2a287b6&tochange=8042121f2dcefb7699d518ff2909c54682c88cb0

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1956486

:emilio, since you are the author of the regressor, bug 1956486, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Daniel Holbert [:dholbert]]

Two quick notes:

• I think STR might be missing a step -- after the pref-flip, you need to reload the testcase. The expectation here is that reloading should take the pref-flip into account, and the lime rect should move to a new spot as a result.

• In builds from around when this regressed, the lime rect doesn't actually ever cover up the red rect (as the testcase's prose says that it should); that's just because our anchor-positioning implementation was more primitive at that point. But you can still tell whether the pref-flip has taken effect, because the lime rect's position still changes when it does take effect.

Comment 3

[Daniel Holbert [:dholbert]]

Also:

• I would guess that this affects other about:config prefs for CSS features, too; not sure precisely which ones.
• This is probably "wontfix" for esr140 since that's not really a place where we expect people to be flipping prefs to enable off-by-default CSS features, and getting upset when that doesn't have an immediate change. Though maybe if the patch ends up trivial/safe enough, we could consider requesting an uplift.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

This seems pretty expected. We don't and never have bothered making css prefs be part of the cache key or so. You can clear site data to get the pref to apply afaict.

Comment 5

[Daniel Holbert [:dholbert]]

(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

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

NS_IMETHODIMP
SharedScriptCache::Observe(nsISupports* aSubject, const char* aTopic,
                           const char16_t* aData) {
  if (strcmp(aTopic, NS_PREFBRANCH_PREFCHANGE_TOPIC_ID) == 0) {
    SharedScriptCache::Clear();

Comment 6

[Daniel Holbert [:dholbert]]

(note that in my previous comment's code-quote, the string passed to AddObserver(...) is a prefix, not necessarily a literal pref name; so we could pass "layout.css" to get notified for all changes to prefs that start with that prefix, just as that code is doing with urlclassifier (which isn't literally watching for a pref with that name, but rather watching the 4 prefs that start with that prefix)

Comment 7

[Emilio Cobos Álvarez [:emilio]]

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).

This has never worked with <link rel=stylesheet> either since all the way back to bug 1599160. And has never worked on SVG-as-image either, for example.

But sure, adding a pref observer and clearing the cache seems reasonable.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1988195 - Simplify script cache handling of prefs. r=arai

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1988195 - Clear style cache on layout.css.* pref changes. r=#layout

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f71fa3d64c81
https://hg.mozilla.org/integration/autoland/rev/952db4da5390
Simplify script cache handling of prefs. r=arai
https://github.com/mozilla-firefox/firefox/commit/1440de652f45
https://hg.mozilla.org/integration/autoland/rev/34f7175aa782
Clear style cache on layout.css.* pref changes. r=dholbert

Comment 11

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/952db4da5390
https://hg.mozilla.org/mozilla-central/rev/34f7175aa782

Comment 12

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Issue is reproducible on a 2025-09-11 Firefox Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 145.0a1 and Firefox 144.0b2 on Windows 10, Ubuntu 22, macOS 15.