[PATCH yew-widget-toolkit 0/2] widget: form: number: fix float display and focus

[PATCH yew-widget-toolkit 0/2] widget: form: number: fix float display and focus

[Christoph Heiss]

Both patches are independent and can be applied separately, if wanted.

Patch #1 fixes the formatting for the `Number` widget with floating
point numbers, when using the step buttons.

Patch #2 fixes focusing the input by click, which currently is
intercepted too early and thus broken.

Christoph Heiss (2):
  widget: form: number: round floats to nearest step value
  widget: form: number: allow focusing the input on mouse click

 src/widget/form/number.rs | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

-- 
2.53.0

[RFC PATCH yew-widget-toolkit 1/2] widget: form: number: round floats to nearest step value

[Christoph Heiss]

E.g. previously, for an input like

    Number::new()
        .name("some-float")
        .min(0.)
        .step(0.1)
        .submit_empty(false)
        .value(0.2)

and pressing the "range-up" button on the input would result in
0.30000000000000004 - which is rather undesirable.

Fix it by multiplying, rounding and then dividing the number again by
some fixed multiplier - in this case, 100_000 was chosen. Should cover
all realistic cases, as it handles up to five fractional digits, which
for UI purposes should (hopefully!) be plenty enough. And if really
needed, could be increased.

Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
---
Marked RFC as it may not be necessarily the *best* solution, but by far
the *simplest*. Happy about other solution suggestions, of course.

I also considered other solutions like e.g. doing the rounding
(implicitly) when formatting the number as string above with
`dom::format_float()` - but that solution seemed more like papering over
the symptoms than fixing the root cause.

 src/widget/form/number.rs | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/widget/form/number.rs b/src/widget/form/number.rs
index e5c849c..6db7063 100644
--- a/src/widget/form/number.rs
+++ b/src/widget/form/number.rs
@@ -68,10 +68,14 @@ impl NumberTypeInfo for f64 {
         crate::dom::format_float(*self)
     }
     fn step_up(&self, step: Option<Self>) -> Self {
-        self + step.unwrap_or(1.0)
+        // Do a little dance here to round to the nearest step value, by multiplying,
+        // rounding to the nearest integer and dividing again
+        ((self + step.unwrap_or(1.0)) * 1e5).round() / 1e5
     }
     fn step_down(&self, step: Option<Self>) -> Self {
-        self - step.unwrap_or(1.0)
+        // Do a little dance here to round to the nearest step value, by multiplying,
+        // rounding to the nearest integer and dividing again
+        ((self - step.unwrap_or(1.0)) * 1e5).round() / 1e5
     }
     fn clamp_value(&self, min: Option<Self>, max: Option<Self>) -> Self {
         self.clamp(min.unwrap_or(f64::MIN), max.unwrap_or(f64::MAX))
-- 
2.53.0

Re: [RFC PATCH yew-widget-toolkit 1/2] widget: form: number: round floats to nearest step value

[Dominik Csapak]

my first instinct would have been to simply change the formatting to 
round to some value of precision but you're right that it's just masking
the symptom.

but I think this patch is also missing some parts. I think
ideally we want to have a 'decimalPrecision' property that controls
the value also on setting/reading, change event etc.
(like it exists in ExtJS)

that should by default use a sensible value (like you did here
with 100_000 it can be just '5')

what do you think?

On 3/19/26 6:04 PM, Christoph Heiss wrote:
> E.g. previously, for an input like
> 
>      Number::new()
>          .name("some-float")
>          .min(0.)
>          .step(0.1)
>          .submit_empty(false)
>          .value(0.2)
> 
> and pressing the "range-up" button on the input would result in
> 0.30000000000000004 - which is rather undesirable.
> 
> Fix it by multiplying, rounding and then dividing the number again by
> some fixed multiplier - in this case, 100_000 was chosen. Should cover
> all realistic cases, as it handles up to five fractional digits, which
> for UI purposes should (hopefully!) be plenty enough. And if really
> needed, could be increased.
> 
> Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
> ---
> Marked RFC as it may not be necessarily the *best* solution, but by far
> the *simplest*. Happy about other solution suggestions, of course.
> 
> I also considered other solutions like e.g. doing the rounding
> (implicitly) when formatting the number as string above with
> `dom::format_float()` - but that solution seemed more like papering over
> the symptoms than fixing the root cause.
> 
>   src/widget/form/number.rs | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/src/widget/form/number.rs b/src/widget/form/number.rs
> index e5c849c..6db7063 100644
> --- a/src/widget/form/number.rs
> +++ b/src/widget/form/number.rs
> @@ -68,10 +68,14 @@ impl NumberTypeInfo for f64 {
>           crate::dom::format_float(*self)
>       }
>       fn step_up(&self, step: Option<Self>) -> Self {
> -        self + step.unwrap_or(1.0)
> +        // Do a little dance here to round to the nearest step value, by multiplying,
> +        // rounding to the nearest integer and dividing again
> +        ((self + step.unwrap_or(1.0)) * 1e5).round() / 1e5
>       }
>       fn step_down(&self, step: Option<Self>) -> Self {
> -        self - step.unwrap_or(1.0)
> +        // Do a little dance here to round to the nearest step value, by multiplying,
> +        // rounding to the nearest integer and dividing again
> +        ((self - step.unwrap_or(1.0)) * 1e5).round() / 1e5
>       }
>       fn clamp_value(&self, min: Option<Self>, max: Option<Self>) -> Self {
>           self.clamp(min.unwrap_or(f64::MIN), max.unwrap_or(f64::MAX))

Re: [RFC PATCH yew-widget-toolkit 1/2] widget: form: number: round floats to nearest step value

[Christoph Heiss]

Thanks for taking a look!

On Mon Mar 23, 2026 at 9:51 AM CET, Dominik Csapak wrote:
> my first instinct would have been to simply change the formatting to
> round to some value of precision but you're right that it's just masking
> the symptom.
>
> but I think this patch is also missing some parts. I think
> ideally we want to have a 'decimalPrecision' property that controls
> the value also on setting/reading, change event etc.
> (like it exists in ExtJS)
>
> that should by default use a sensible value (like you did here
> with 100_000 it can be just '5')
>
> what do you think?

Yeah, I was thinking about that too briefly. Would be bit more effort,
but sure, definitely makes sense!

I'll spin a v2 with that, mostly wanted to get some early feedback with
this patch, whether the overall approach of this fix is acceptable.

[PATCH yew-widget-toolkit 2/2] widget: form: number: allow focusing the input on click

[Christoph Heiss]

The `.prevent_default()` on the input elements `onmousedown` handler is
not needed and actually prevents the input from being focused by
clicking, since the event will never reach it. Drop it.

The returned `SpinnerStop` value is just a dummy, so safe to remove the
entire handler.

Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
---
 src/widget/form/number.rs | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/src/widget/form/number.rs b/src/widget/form/number.rs
index 6db7063..82d66b4 100644
--- a/src/widget/form/number.rs
+++ b/src/widget/form/number.rs
@@ -665,12 +665,6 @@ impl<T: NumberTypeInfo> ManagedField for NumberField<T> {
             }
         });
 
-        let on_mouse_down = ctx.link().callback(|event: MouseEvent| {
-            // prevent focus loss
-            event.prevent_default();
-            Msg::SpinnerStop // dummy
-        });
-
         let input_props = props.input_props.clone();
 
         let inputmode = if T::is_decimal() {
@@ -702,7 +696,6 @@ impl<T: NumberTypeInfo> ManagedField for NumberField<T> {
                     event.prevent_default();
                 }
             })
-            .onmousedown(on_mouse_down)
             .into_html_with_ref(self.input_ref.clone());
 
         let mut input_container = Tooltip::empty()
-- 
2.53.0

Re: [PATCH yew-widget-toolkit 2/2] widget: form: number: allow focusing the input on click

[Dominik Csapak]

@Dietmar

i applied this one since it fixed the focus issue for nubmer fields.
Looking at the code this slipped in with the changes to the managedfield
interface, but the commit message (and code) don't give a full 
explanation for this onmousedown handler.
(only 'prevent focus loss')

Can you remember in what situations we lost the focus or where there
were problems? Since i couldn't find any...

On 3/19/26 6:04 PM, Christoph Heiss wrote:
> The `.prevent_default()` on the input elements `onmousedown` handler is
> not needed and actually prevents the input from being focused by
> clicking, since the event will never reach it. Drop it.
> 
> The returned `SpinnerStop` value is just a dummy, so safe to remove the
> entire handler.
> 
> Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
> ---
>   src/widget/form/number.rs | 7 -------
>   1 file changed, 7 deletions(-)
> 
> diff --git a/src/widget/form/number.rs b/src/widget/form/number.rs
> index 6db7063..82d66b4 100644
> --- a/src/widget/form/number.rs
> +++ b/src/widget/form/number.rs
> @@ -665,12 +665,6 @@ impl<T: NumberTypeInfo> ManagedField for NumberField<T> {
>               }
>           });
>   
> -        let on_mouse_down = ctx.link().callback(|event: MouseEvent| {
> -            // prevent focus loss
> -            event.prevent_default();
> -            Msg::SpinnerStop // dummy
> -        });
> -
>           let input_props = props.input_props.clone();
>   
>           let inputmode = if T::is_decimal() {
> @@ -702,7 +696,6 @@ impl<T: NumberTypeInfo> ManagedField for NumberField<T> {
>                       event.prevent_default();
>                   }
>               })
> -            .onmousedown(on_mouse_down)
>               .into_html_with_ref(self.input_ref.clone());
>   
>           let mut input_container = Tooltip::empty()

Re: [PATCH yew-widget-toolkit 2/2] widget: form: number: allow focusing the input on click

[Dietmar Maurer]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]

> Can you remember in what situations we lost the focus or where there
were problems? Since i couldn't find any...
Sorry, I can't remember.

[-- Attachment #2: Type: text/html, Size: 748 bytes --]

partially applied: [PATCH yew-widget-toolkit 0/2] widget: form: number: fix float display and focus

[Dominik Csapak]

On Thu, 19 Mar 2026 18:04:16 +0100, Christoph Heiss wrote:
> Both patches are independent and can be applied separately, if wanted.
> 
> Patch #1 fixes the formatting for the `Number` widget with floating
> point numbers, when using the step buttons.
> 
> Patch #2 fixes focusing the input by click, which currently is
> intercepted too early and thus broken.
> 
> [...]

Applied the second one for now, thanks!

See my comments on patch 1/2 for why i didn't apply that.

[2/2] widget: form: number: allow focusing the input on click
      commit: 487f9d905c57b746d7aa6979e7b6a241bfa135c5