Fix position when use anchor css properties

[joaom00]

Description

Reset the middleware lifecycle to calculate the right position when using --radix-popper-anchor-width or --radix-popper-anchor-height.

See the behavior in some primitives although works with Select

https://codesandbox.io/p/sandbox/cocky-wood-wgqnuy

Fixes #1968
Fixes #2017

[benoitgrelard]

I can see that fixes the issue, but I'm a little unclear as to why it needs to be in this middleware, or why it happens.
Do you have a bit more understanding here @joaom00?

[joaom00]

@benoitgrelard My understanding is that when the content is mounted all middlewares use the initial width which would be the total size of the content, let's say 66px, and when the CSS variable is defined in the middleware the width of the floating element changes, let's say 100px now, and then I ask to get the updated width, I check if there has been a change, if so I reset the middleware lifecycle with the new width. If the lifecycle is not reset, all other middlewares will continue to use the stale 66px width value.

In fact, this code is very similar to the one internally in the size middleware, if you want we can set the anchor CSS variables there and remove the anchorCssProperties middleware.

[roryhen]

Just to add my experience here. Without knowing the implementation details what it seems like is happening is that it is calculating the position of the PopoverContent (or MenubarContent, DropdownContent, etc.) based on it's intrinsic size. In @joaom00's provided repro, when you toggle the width off for PopoverContent in DevTools for example, you'll see that the content seems to be positioned correctly on toggle, although not the desired matching width to the trigger.

[benoitgrelard]

I see that makes sense.

In fact, this code is very similar to the one internally in the size middleware, if you want we can set the anchor CSS variables there and remove the anchorCssProperties middleware.

If we did this, would this mean we don't need all this extra logic as it would already be invalidated by the internals of the size middleware?

[joaom00]

If we did this, would this mean we don't need all this extra logic as it would already be invalidated by the internals of the size middleware?

Yes, what I understood is that size() was made to perform any mutation in the size of the floating element

[benoitgrelard]

Let's try that then as I think it might make more sense to group anything size related within that middleware and not have the extra invalidation code as its the same concern.

[joaom00]

I had to change the position of the arrow middleware to after the size because it was not able to position the arrow correctly

[andree-gojek]

This still happens in @radix-ui/react-dropdown-menu