josepharhar / offsetparent-polyfills Goto Github PK

[Continuation of the discussion on chromium bugs regarding the new offset behavior (now aligned with Firefox).]

The upgrade to Chrome 109 seems to have altered the behavior of this polyfill. I'm using isNewBehavior=false, assuming this is the flag for reproducing the old (Chrome <= 108) behavior. In my classical example using offsetLeft and -Top to calculate the anchor points of edge in a graphical editor, elements in shadowroots now return negative values, resulting in unexpected behavior:

chrome_bc5T6XQF45.mp4

For a live example (and live programming environment), you can head to https://lively-kernel.org/lively4/composed-offset/start.html?load=https://lively-kernel.org/lively4/composed-offset/demos/offset/offset-left-top.md (only runs in Chrome).

Some of the values seem to be computed correctly, some do not (the accumulating substraction seems off, or is just applied to the wrong elements (https://github.com/josepharhar/offsetparent-polyfills/blob/main/offsetParent-polyfill.js#L105))

Turning isNewBehavior to true has other effects, particularly, not changing the offset of an element when moved. In the below video, the edge in the top left should follow the movement of the node:

isNewBehavior.true.mp4

Very interesting: the offset of a web-component directly in the body still seems to be computed correctly (here 43, 36 for a lively-window) as show in this test (lower is closer to the root):

However, a div in the component's shadowroot has the exact same offset, just negative (here -43, -36 for div.window)

"Unsure, where to report this due to many moving parts. I at least know that you are very knowledgeable in this topic."

Browser: Chrome Version 108.0.5359.73 (Offizieller Build) (64-Bit)

I'm using this polyfill (all 3 methods) on a deeply nested element in a recursive manner to walk up the parent chain until a designated parent is found. While walking, we accumulate the offset. I use the result to position another element (an svg path).

While everything works fine, once I set the css property filter on any element in the parent chain (or a child of it), it seems to not contribute to offset computation anymore. This results in the following effect:

chrome_pYggvumWxL.mp4

To reproduce:

• navigate to https://lively-kernel.org/lively4/composed-offset/start.html?load=https://lively-kernel.org/lively4/composed-offset/demos/offset/offset-left-top.md
  • same is used as an example in https://bugs.chromium.org/p/chromium/issues/detail?id=1334556#c13
• open the Chrome DevTools
• Select the out circle element in the Elements tab
• choose a parent, e.g. the div with id=container
• add a filter property to its style, e.g. filter: invert(1);
• move the port by dragging the 'simple node' label

My question is if this change in behavior due to the filter property is intentional or not?

According to https://drafts.fxtf.org/filter-effects/#FilterProperty filter inserts a containing block, but I'm unsure, if this should affect offset*.

A value other than none for the filter property results in the creation of a containing block for absolute and fixed positioned descendants unless the element it applies to is a document root element in the current browsing context. The list of functions are applied in the order provided.