This issue has been known for a long time, I'm opening a bug for the record.
In general for delimiters (parenthesis, brackets...) the width of size variants and glyph assembly is the same as the base character, so the stretchy operator width does not depend on the stretch height and we can compute the preferred width without knowing the height. Also, for large operators in displaystyle (e.g. sums), we already know which glyph will be picked when we compute the preferred width, so that's not a problem either.
However, there are some cases where the glyph width strongly depends on the stretch height that will be used at the end. For example "FRACTION SLASH" in the STIX Math or the large operators when they have the "stretchy" property. Fortunately, these operators are not stretchy by default so the situation does not really happen in practice. However, it would be good to find a solution that does not reintroduce the security issue of bug 121416, perhaps following what Gecko does.
See also bug 122837 comment 2, for a related issue which seems specific to STIX fonts. I'll have to check if there are similar issues in MATH fonts.
Created attachment 267370 [details]
This shows different parenthesis size. The width is slightly different. Actually, only the base size is significantly narrower than the others.
Created attachment 267381 [details]
Created attachment 271333 [details]
Created attachment 271340 [details]
Created attachment 283599 [details]
This is a new testcase with better explanation. The logical width computation is now correct in WebKit. However, the preferred width is sometimes overestimated. Gecko behaves the same and I'm not sure there is an easy way to solve this issue, though.