Bug 1466008 Comment 12 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
> Yeah, so, that reftest relies on the observable effects of contain creating a fixed-pos containing block.
> 
> Other properties which are preffed with the same effect are the individual transform properties (`layout.css.individual-transform.enabled`)

This pref shipped as default-enabled in Firefox 72 (bug 1424900), and now we're up to having released Firefox 74, so it's kind of in the same boat as `contain` in the sense that we're unlikely to un-ship it & we might as well remove its pref if possible.  So, I'm hesitant to just kick the can over to this property.

> or `backdrop-filter` (`layout.css.backdrop-filter.enabled`).

That one might be a good fit, since it's complicated & will likely be webrender-dependent for the foreseeable future & hence we'll probably want to keep it preffable for a while.

Question: is it OK that the pref is off by default? (i.e. were you trying to exercise some condition where a default-enabled-property is dynamically preffed off, or is it sufficient for the property to simply be disabled, period [whether it's default-disabled or dynamically disabled]?)
(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
> Yeah, so, that reftest relies on the observable effects of contain creating a fixed-pos containing block.
> 
> Other properties which are preffed with the same effect are the individual transform properties (`layout.css.individual-transform.enabled`)

This pref shipped as default-enabled in Firefox 72 (bug 1424900), and now we're up to having released Firefox 74, so it's kind of in the same boat as `contain` in the sense that we're unlikely to un-ship it & we might as well remove its pref if possible.  So, I'm hesitant to just kick the can over to this property.

> or `backdrop-filter` (`layout.css.backdrop-filter.enabled`).

That one might be a good fit, since it's complicated & will likely be webrender-dependent for the foreseeable future & hence we'll probably want to keep it preffable for a while.

Question: is it OK that the pref is off by default? (i.e. were you trying to exercise some condition where a default-enabled-property is dynamically preffed off, or is it sufficient for the property to simply be disabled, period [regardless of whether it's default-disabled or dynamically disabled]?)

Back to Bug 1466008 Comment 12