Vertical position of popovers no longer adjusting with page zoom factor in PWA!

[Jaifroid]

This is bizarre, because I worked a lot on that, and haven't touched the code, but it now appears that altering the page zoom factor in-app is not adjusting the vertical positioning of popovers, leading them to be positioned over (and hide) the link the user may wish to click.

Grrr...

[Jaifroid]

OK, I've discovered the reason for this. It's because Firefox have just introduced support for the zoom CSS property (since 126 - see https://caniuse.com/css-zoom), which caused the feature detection to go wonky.

[Jaifroid]

The problem is more widespread, and is due to the fact that the interaction between the zoom property and getBoundingClientRect has changed in recent browsers due to standardization.

Even jQuery devs are discucssing this: see jquery/jquery-ui#2292 .

We need to use a different value, such as offsetTop to get the unadjusted values, because we're now in a situation where we can't detect whether getBoundingCleintRect() is giving us values divided by the zoom factor or not, depending on the date of the exact same browser!

[Jaifroid]

See also https://developer.chrome.com/release-notes/128?hl=en#disable_standardized_css_zoom . Chromium 128 forced the standardization, and there is a flag to disable the new behaviour (but that would only buy some time)...

[Jaifroid]

We can probably detect the new API by adapting this code (basically comparing offsetTop and getBoundingClientRect().top:

// Set isNewRectAPI based on a specific value, not according to multiple browser versions.
var originTop = $("#some element whose position is held").prop("offsetTop");
var boundingClientRectTop = document.getElementById("#some element whose position is held").getBoundingClientRect().top;
isNewRectAPI = Math.abs(originTop - boundingClientRectTop) > Math.abs(originTop*document.body.style.zoom - boundingClientRectTop)