1925508 - developer.apple.com - The page is rendered broken

Status: REOPENED

(Web Compatibility :: Interventions, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile 133.0

Steps to reproduce:

1. Navigate to: https://developer.apple.com/library/archive/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/AdoptingOpenGLES3/AdoptingOpenGLES3.html
2. Observe

Expected Behavior:
The page is rendered correctly

Actual Behavior:
The page appears zoomed in

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, and Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/142901

Comment 1

[Raul Bucata]

Attachment: Screenshot_13.png

Comment 2

[Sky Schubert [:skyschub]]

We used to ship an intervention for this, 5 years ago: https://github.com/mozilla-extensions/webcompat-addon/pull/75/commits/9a5b0f36ccce8f673b68ccf9bb70014a3bd5ca99

Comment 3

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1925508 - re-add the Android CSS intervention for developer.apple.com from bug 1570328; r?denschub

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0b311ae0356e
re-add the Android CSS intervention for developer.apple.com from bug 1570328; r=denschub,webcompat-reviewers

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/0b311ae0356e

Comment 6

[Thomas Wisniewski [:twisniewski]]

This should have been left open, pardon the bugspam.

Comment 7

[Daniel Holbert [:dholbert]]

I can reproduce in RDM. Someone on the layout team can take a look (maybe me) --> moving to that diagnosis queue.

Comment 8

[Daniel Holbert [:dholbert]]

This boils down to this one rule, where they're assuming that browsers recognize/honor either zoom or -moz-transform but not both:

@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.]

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Yeah, interestingly it seems this site was broken before supporting zoom, right? Because it was lacking the transform-origin

Comment 10

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1925508 - fix the Android CSS intervention for developer.apple.com; r?denschub

Comment 11

[Thomas Wisniewski [:twisniewski]]

Thanks for the proposed improvement, dholbert.. I just posted a patch, and we should still be able to get it into 134.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9bcf373df499
fix the Android CSS intervention for developer.apple.com; r=denschub,webcompat-reviewers

Comment 13

[Goloman Adrian[:agoloman]]

https://hg.mozilla.org/mozilla-central/rev/9bcf373df499

Comment 14

[Thomas Wisniewski [:twisniewski]]

Agh, I forgot to mark this as leave-open again. Sorry for the bugspam.

Comment 15

[Daniel Holbert [:dholbert]]

Thanks!

Note: even though this bug is open, there's unlikely to be any further fix/mitigation here, aside from perhaps convincing Apple to remove the -moz-transform usage in their CSS here (and they may prefer not to touch the CSS, given that the site-in-question is a historical/archived version of some documentation).

I think relying-on-sitepatches-indefinitely is our working plan for sites like this that use both -moz-transform and zoom on the same element, per bug 1901497 comment 8.

Comment 16

[Calin Tanase]

The issue is still reproducible on latest Nightly (v138) if intervention extension.webcompat.perform_injections is set to false.

Comment 17

[Daniel Holbert [:dholbert]]

That's expected; this is already diagnosed, and there's nothing we can really do here (without causing more breakage elsewhere), besides a sitepatch (which we have, yay!) and possibly outreach to get the site fixed. See comment 15 and more details in comment 8.

Comment 18

[Thomas Wisniewski [:twisniewski]]

The intervention is only really needed here if the pref layout.css.prefixes.transforms is true. Since we have the ability to gate by pref-values, let's use it to optimize things slightly.

Comment 19

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1925508 - update our Android-only webcompat intervention for developer.apple.com to only be enabled when layout.css.prefixes.transforms=true; r?denschub

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e0328d0c717
update our Android-only webcompat intervention for developer.apple.com to only be enabled when layout.css.prefixes.transforms=true; r=denschub,webcompat-reviewers

Comment 21

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/8e0328d0c717