Bugzilla

This boils down to this one rule, where they're assuming that browsers recognize/honor either `zoom` or `-moz-transform` but not both:
```css
@media only screen and (min-device-width: 320px) and (max-device-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px) {

#tocContainer {
	border-right: 0 !important;
	margin-top: 11px;
	zoom: 1.4;
	-moz-transform: scale(1.4);
}
```

**The problem:**
We recognize/honor both `zoom` and `-moz-transform` so we double-apply the scale here, which is why it looks extra-zoomed-in in Firefox.
The issue goes away if I toggle `layout.css.prefixes.transforms` to `false` (to make us ignore `-moz-transform`).

I think we were considering unsupporting `-moz-transform` at one point (bug 1855763), but it seems that created more pain than it fixed, and we're now trying to lean on sitepatching as a way to mitigate this sort of problem (see bug 1901497 comment 8), and we've added back support for both properties (including in release) in bug 1886134.

**Notes on our intervention:**
Per above, landing an intervention is correct. However, the intervention that we landed here (comment 4) only helps *somewhat* -- I think the main benefit that it brought us was from the `transform-origin: 0 0;` which makes the large content only grow/overflow towards the bottom-right, so that it remains scrollable.  But it's still much bigger in Firefox as compared to Chrome (even with the intervention that we landed) because we're still honoring two different properties that cause it to scale.

twisniewski: could you try adjusting our intervention to simply reset a single property (either `zoom: initial` or `-moz-transform: initial`) in the `#tocContainer` style rule (and not change any other styles)?  That should be a more-targeted and more-complete way to mitigate this.  With that, I think we'll be able to consider this ~fixed (indefinitely leaning on a sitepatch, which we're kinda stuck with per bug 1901497 comment 8).

This boils down to this one rule, where they're assuming that browsers recognize/honor either `zoom` or `-moz-transform` but not both:
```css
@media only screen and (min-device-width: 320px) and (max-device-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px) {

#tocContainer {
	border-right: 0 !important;
	margin-top: 11px;
	zoom: 1.4;
	-moz-transform: scale(1.4);
}
```

**The problem:**
We recognize/honor both `zoom` and `-moz-transform` so we double-apply the scale here, which is why it looks extra-zoomed-in in Firefox.
The issue goes away if I untick `-moz-transform` or toggle `layout.css.prefixes.transforms` to `false` (to make us ignore `-moz-transform`).

I think we were considering unsupporting `-moz-transform` at one point (bug 1855763), but it seems that created more pain than it fixed, and we're now trying to lean on sitepatching as a way to mitigate this sort of problem (see bug 1901497 comment 8), and we've added back support for both properties (including in release) in bug 1886134.

**Notes on our intervention:**
Per above, landing an intervention is correct. However, the intervention that we landed here (comment 4) only helps *somewhat* -- I think the main benefit that it brought us was from the `transform-origin: 0 0;` which makes the large content only grow/overflow towards the bottom-right, so that it remains scrollable.  But it's still much bigger in Firefox as compared to Chrome (even with the intervention that we landed) because we're still honoring two different properties that cause it to scale.

twisniewski: could you try adjusting our intervention to simply reset ~a single property~ the `-moz-transform property` (~either `zoom: initial` or~ `-moz-transform: initial`) in the `#tocContainer` style rule (and not change any other styles)?  That should be a more-targeted and more-complete way to mitigate this.  With that, I think we'll be able to consider this ~fixed (indefinitely leaning on a sitepatch, which we're kinda stuck with per bug 1901497 comment 8).

[EDIT: we need to specifically reset `-moz-transform` and not `zoom`.  If we leave the site's `-moz-transform` styling in place, it needs `transform-origin` as well in order to look OK.  So: it's cleanest to just add `-moz-transform: initial` and call it good, I think.]

This boils down to this one rule, where they're assuming that browsers recognize/honor either `zoom` or `-moz-transform` but not both:
```css
@media only screen and (min-device-width: 320px) and (max-device-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px) {

#tocContainer {
	border-right: 0 !important;
	margin-top: 11px;
	zoom: 1.4;
	-moz-transform: scale(1.4);
}
```

**The problem:**
We recognize/honor both `zoom` and `-moz-transform` so we double-apply the scale here, which is why it looks extra-zoomed-in in Firefox.
The issue goes away if I untick `-moz-transform` or toggle `layout.css.prefixes.transforms` to `false` (to make us ignore `-moz-transform`).

I think we were considering unsupporting `-moz-transform` at one point (bug 1855763), but it seems that created more pain than it fixed, and we're now trying to lean on sitepatching as a way to mitigate this sort of problem (see bug 1901497 comment 8), and we've added back support for both properties (including in release) in bug 1886134.

**Notes on our intervention:**
Per above, landing an intervention is correct. However, the intervention that we landed here (comment 4) only helps *somewhat* -- I think the main benefit that it brought us was from the `transform-origin: 0 0;` which makes the large content only grow/overflow towards the bottom-right, so that it remains scrollable.  But it's still much bigger in Firefox as compared to Chrome (even with the intervention that we landed) because we're still honoring two different properties that cause it to scale.

twisniewski: could you try adjusting our intervention to simply reset ~a single property~ the `-moz-transform property` (~either `zoom: initial` or~ `-moz-transform: initial`) in the `#tocContainer` style rule (and not change any other styles)?  That should be a more-targeted and more-complete way to mitigate this.  With that, I think we'll be able to consider this ~fixed (indefinitely leaning on a sitepatch, which we're kinda stuck with per bug 1901497 comment 8).

[EDIT: when posting this comment I had thought we could reset either zoom or -moz-transform, but on further testing it looks like it's cleanest to **specifically reset `-moz-transform`** and not `zoom`**.  If we leave the site's `-moz-transform` styling in place, then we also need to add `transform-origin: 0 0` as well in order to look OK.  So: the cleanest one-liner intervention is just add `-moz-transform: initial` and call it good]

This boils down to this one rule, where they're assuming that browsers recognize/honor either `zoom` or `-moz-transform` but not both:
```css
@media only screen and (min-device-width: 320px) and (max-device-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px) {

#tocContainer {
	border-right: 0 !important;
	margin-top: 11px;
	zoom: 1.4;
	-moz-transform: scale(1.4);
}
```

**The problem:**
We recognize/honor both `zoom` and `-moz-transform` so we double-apply the scale here, which is why it looks extra-zoomed-in in Firefox.
The issue goes away if I untick `-moz-transform` or toggle `layout.css.prefixes.transforms` to `false` (to make us ignore `-moz-transform`).

I think we were considering unsupporting `-moz-transform` at one point (bug 1855763), but it seems that created more pain than it fixed, and we're now trying to lean on sitepatching as a way to mitigate this sort of problem (see bug 1901497 comment 8), and we've added back support for both properties (including in release) in bug 1886134.

**Notes on our intervention:**
Per above, landing an intervention is correct. However, the intervention that we landed here (comment 4) only helps *somewhat* -- I think the main benefit that it brought us was from the `transform-origin: 0 0;` which makes the large content only grow/overflow towards the bottom-right, so that it remains scrollable.  But it's still much bigger in Firefox as compared to Chrome (even with the intervention that we landed) because we're still honoring two different properties that cause it to scale.

twisniewski: could you try adjusting our intervention to simply reset ~a single property~ the `-moz-transform property` (~either `zoom: initial` or~ `-moz-transform: initial`) in the `#tocContainer` style rule (and not change any other styles)?  That should be a more-targeted and more-complete way to mitigate this.  With that, I think we'll be able to consider this ~fixed (indefinitely leaning on a sitepatch, which we're kinda stuck with per bug 1901497 comment 8).

[EDIT: when posting this comment I had thought we could reset **either** zoom or -moz-transform, but on further testing it looks like it's cleanest to **specifically reset `-moz-transform`** and not `zoom`.  If we leave the site's `-moz-transform` styling in place, then we also need to add `transform-origin: 0 0` as well in order to look OK.  So: the cleanest one-liner intervention is just add `-moz-transform: initial` and call it good]

This boils down to this one rule, where they're assuming that browsers recognize/honor either `zoom` or `-moz-transform` but not both:
```css
@media only screen and (min-device-width: 320px) and (max-device-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px), (min-device-width: 1024px) and (max-device-width: 1024px) and (min-device-height: 1366px) and (max-device-height: 1366px) and (min-width: 320px) and (max-width: 980px) {

#tocContainer {
	border-right: 0 !important;
	margin-top: 11px;
	zoom: 1.4;
	-moz-transform: scale(1.4);
}
```

**The problem:**
We recognize/honor both `zoom` and `-moz-transform` so we double-apply the scale here, which is why it looks extra-zoomed-in in Firefox.
The issue goes away if I untick `-moz-transform` or toggle `layout.css.prefixes.transforms` to `false` (to make us ignore `-moz-transform`).

I think we were considering unsupporting `-moz-transform` at one point (bug 1855763), but it seems that created more pain than it fixed, and we're now trying to lean on sitepatching as a way to mitigate this sort of problem (see bug 1901497 comment 8), and we've added back support for both properties (including in release) in bug 1886134.

**Notes on our intervention:**
Per above, landing an intervention is correct. However, the intervention that we landed here (comment 4) only helps *somewhat* -- I think the main benefit that it brought us was from the `transform-origin: 0 0;` which makes the large content only grow/overflow towards the bottom-right, so that it remains scrollable.  But it's still much bigger in Firefox as compared to Chrome (even with the intervention that we landed) because we're still honoring two different properties that cause it to scale.

twisniewski: could you try adjusting our intervention to simply reset ~a single property~ the `-moz-transform property` (~either `zoom: initial` or~ `-moz-transform: initial`) in the `#tocContainer` style rule (and not change any other styles)?  That should be a more-targeted and more-complete way to mitigate this.  With that, I think we'll be able to consider this ~fixed (indefinitely leaning on a sitepatch, which we're kinda stuck with per bug 1901497 comment 8).

[EDIT: when posting this comment I had thought we could reset **either** zoom or -moz-transform, but on further testing it looks like it's cleanest to **specifically reset `-moz-transform`** and not `zoom`.  If we reset `zoom` and leave the site's `-moz-transform` styling in place, then we still overflow on all sides and we need to add `transform-origin: 0 0` as well in order to look OK.

So: I think the cleanest one-liner intervention is just add `-moz-transform: initial` for this element, and remove all the other properties that we're currently setting in our intervention, and call it good.]