Bug 263454 – CSS 3D transforms break depending on container width

• Status: REOPENED
• Component: CSS

[Don McCurdy]

Created attachment 468285 [details]
Expected result vs. actual result.

## Steps to reproduce

(1) Load the JSFiddle (https://jsfiddle.net/donmccurdy/twy3p2zv/), which sets up (1) a WebGL canvas, and (2) an overlay div with matching CSS 3D transforms as described below
(2) Adjust the "width" and "height" sliders, scaling the container div
(3) Watch position of the ":)" relative to the box

## Expected result

The CSS 3D transform should work the same way regardless of the width/height of the parent container, keeping the ":)" div centered relative to the WebGL canvas.

## Actual result

The position of the ":)" div shifts significantly for certain values of "width" and "height" In my tests, even-numbered pixel widths and heights seem to avoid the error.

## Additional information

The CSS 3D transforms used are coming from THREE.CSS3DRenderer, as found here: https://github.com/mrdoob/three.js/blob/181e04eea8b569dc09048f9dc644310ed6b745a6/examples/jsm/renderers/CSS3DRenderer.js#L128-L183. To briefly describe their purpose and the DOM structure:

1. An outer "viewElement" is sized to match the canvas, and uses `transform-origin: 0px 0px;` and `perspective: 857.803px;` (or similar) to match WebGL perspective.
2. Inside that, "cameraElement" uses `transform-style: preserve-3d;` and a matrix3d transform matching the WebGL camera transform.
3. Within that, an "objectElement" uses a matrix3d transform to position the div within the 3D scene.

This is a means of positioning HTML content over a specific region of a 3D scene drawn by WebGL, useful where we want to ensure annotations and interactive elements are done in accessible HTML, on top of a less-accessible WebGL canvas. Versions of this are implemented separately by three.js (https://threejs.org/), React Three Fiber (https://docs.pmnd.rs/react-three-fiber/), and threlte (https://threlte.xyz/), and all implementations hit the same bug.

In my writeup for three.js (https://github.com/mrdoob/three.js/issues/26950) I've noted a similar bug in Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=1494366#makechanges), although it triggers under different circumstances – based on the left and top offsets of the parent element, not the width and height. Firefox displays the element position correctly regardless of offset and size, though it does have some other problems when "position:sticky" is introduced to a parent. In both Safari and Firefox, the element is also rendered at lower resolution than might be ideal.

If needed, I can come up with a version of this JSFiddle that doesn't depend on three.js.

[Radar WebKit Bug Importer]

<rdar://problem/117594127>

[Karl Dubost]

Created attachment 468498 [details]
rendering in safari, firefox, chrome

[Karl Dubost]

Created attachment 468500 [details]
rendering in safari, firefox, chrome - shifted

Here we can see how the smiley has shifted while other browsers left the smiley centered.

[Ahmad Saleem]

@Don - I am unable to reproduce this in Safari Technology Preview 194 and now smiley seems to be in centre like other browsers (Chrome Canary 127 and Firefox Nightly 127).

Can you confirm?

@Karl - any input? or if you are getting different results.

[Karl Dubost]

This is fixed also in STP 191.

[Don McCurdy]

Hmm, testing in STP Release 195 (Safari 17.4, WebKit 19619.1.15.0.1), I'm still seeing the issue in the JSFiddle link shared above. The smiley is initially centered, but shifts with any change to width or height.

I had to swap the CDN in the JSFiddle from Unpkg to JSDeliver, was getting some errors from Unkpg, but that should be unrelated here.

[Ahmad Saleem]

It seems that moving slider of width and height, does make smiley jump rather than being at same place, like it suppose to and how Chrome Canary 134 behaves. So this is still happening. So reopening.