From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 5F5781FF146 for ; Tue, 09 Jun 2026 09:12:35 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3B6466ADC; Tue, 9 Jun 2026 09:12:35 +0200 (CEST) From: Dominik Csapak To: yew-devel@lists.proxmox.com Subject: [PATCH yew-widget-toolkit] touch: slidable: use bounding client rect for width Date: Tue, 9 Jun 2026 09:11:10 +0200 Message-ID: <20260609071200.411677-1-d.csapak@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.049 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [mod.rs] Message-ID-Hash: 4EWFR5ETBMVL5Z2EUBXU2Q6LNDG4JN4I X-Message-ID-Hash: 4EWFR5ETBMVL5Z2EUBXU2Q6LNDG4JN4I X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Yew framework devel list at Proxmox List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: when calculating the width of the left and right actions, using offsetWidth is problematic since it's always returned as an integer[0]. Since the browser calculates the sizes with fractional pixels, it can happen that this is too narrow, impacting the flex layout. It'll always be less than one pixel, but it can lead to e.g. text wrapping or similar effects, disturbing the overall layout here. Using the width of boundingClientRect returns a floating point, so this should be the correct size (including sub-pixels). 0: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetWidth Signed-off-by: Dominik Csapak --- this is not a replacement for the assets fix for setting the nowrap on the slidable action, but it is an additional correctness fix. src/touch/slidable/mod.rs | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/touch/slidable/mod.rs b/src/touch/slidable/mod.rs index ae45e29..d1959ba 100644 --- a/src/touch/slidable/mod.rs +++ b/src/touch/slidable/mod.rs @@ -266,8 +266,9 @@ impl Component for PwtSlidable { .left_action_ref .cast::() .unwrap() - .offset_width() - .max(0) as f64; + .get_bounding_client_rect() + .width() + .max(0.0); if width > (left_size + 1.0) { self.left_size = left_size; @@ -283,8 +284,9 @@ impl Component for PwtSlidable { .right_action_ref .cast::() .unwrap() - .offset_width() - .max(0) as f64; + .get_bounding_client_rect() + .width() + .max(0.0); if width > (right_size + 1.0) { self.right_size = right_size; -- 2.47.3