On Thu, 29 Oct 2026 18:13:42 GMT, Phil Race <[email protected]> wrote:
>> FrameSetView parses percentage values from HTML frameset attributes using an >> int. >> So, large values can overflow and become zero or negative. >> For example, 4294967296% which is 2^32 is parsed as zero, causing the frame >> to receive an incorrect share of the available space. >> >> The fix checks whether adding the next digit would exceed Integer.MAX_VALUE. >> If so, it returns Integer.MAX_VALUE. >> Values within the supported range retain their existing behavior. >> >> The subsequent percentage calculations also is needed to use long arithmetic >> to prevent overflow, when adding percentages, normalizing them to a total of >> 100%, and converting percentages into pixel sizes. >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.desktop/share/classes/javax/swing/text/html/FrameSetView.java line > 320: > >> 318: char ch = mixedStr.charAt(i); >> 319: if (Character.isDigit(ch)) { >> 320: int digit = Character.digit(ch, 10); > > This code is only used for percentages. So surely we just bail when it hits > 100 and return that .. It will fix the overflow but the capping will cause a behaviour change in frame scaling. FrameSetView adds the percentages together. If their total exceeds 100, it scales each value using: normalized = value * 100 / total; as seen in l150 Suppose frame has 2 columns with 200%,50% ratio then we will have First frame: 200 × 100 / 250 = 80% Second frame: 50 × 100 / 250 = 20% This preserves their original 4:1 ratio. With the new cap, the parser returns 100 and 50, giving a total of 150 First frame: 100 × 100 / 150 = 66% Second frame: 50 × 100 / 150 = 33% so capping each percentage changes the proportions With current PR fix, this ratio is maintained.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33623#discussion_r4420031408
