Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GUI: RBF: improve feerate text input #860

Closed
darosior opened this issue Dec 8, 2023 · 4 comments · Fixed by #1097
Closed

GUI: RBF: improve feerate text input #860

darosior opened this issue Dec 8, 2023 · 4 comments · Fixed by #1097
Assignees
Labels
Enhancement Improving an existing functionality Good first issue Good for newcomers GUI gui related

Comments

@darosior
Copy link
Member

darosior commented Dec 8, 2023

It might be better not to trim the feerate value as it's difficult to edit a single-digit value. It's not possible to delete the existing value and enter a new one and we have to instead add a second digit and delete the first.

Originally posted by @jp1ac4 in #852 (comment)

@darosior darosior added Good first issue Good for newcomers GUI gui related Enhancement Improving an existing functionality labels Dec 8, 2023
@faytey
Copy link

faytey commented Feb 27, 2024

Hello is this issue still available, i'd love to work on it and get a bit more context thanks

@darosior
Copy link
Member Author

#852 introduced support for RBF'ing unconfirmed transactions in the GUI. This is presented as a button you click which opens a modal for you to set the feerate of the new transaction. The text input for the feerate of the new transaction however gets trimmed as you edit it, which makes it difficult to edit single-digit values.

@jp1ac4 what do you think a fix should be here? Simply using an untrimmed form::Form?

@jp1ac4
Copy link
Collaborator

jp1ac4 commented Feb 27, 2024

Hi @faytey, thanks for offering to work on this issue.

I initially thought the problem was to do with trimming the form values:

form::Form::new_trimmed("", feerate, move |msg| {

But we don't have this issue on the normal Send page, which uses the same type of form:

form::Form::new_trimmed(

I think rather the problem is how we handle the feerate being edited. We only save the form value if it can be parsed as u64:

self.feerate_val.value = s;

But I think we should save the form value regardless of whether it can be parsed, and only its validity should depend on the result of parsing.

@jp1ac4
Copy link
Collaborator

jp1ac4 commented Apr 1, 2024

Hi @faytey, are you still working on this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Improving an existing functionality Good first issue Good for newcomers GUI gui related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants