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.

Sign up for GitHub

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

Jump to bottom

Footer gets updated as many times as the edit key is pressed on any uneditable message #647

Closed
preetmishra opened this issue May 4, 2020 · 5 comments · Fixed by #748
Closed

Footer gets updated as many times as the edit key is pressed on any uneditable message #647

preetmishra opened this issue May 4, 2020 · 5 comments · Fixed by #748
Labels
bug Something isn't working
Milestone
0.7.0

Comments

@preetmishra
Copy link
Member

Steps to reproduce:

  • Move focus to any message that you can't edit
  • Press e multiple times
  • Press any other key to trigger the behaviour
@neiljp
Copy link
Collaborator

neiljp commented May 5, 2020

To clarify, for me it updates the footer multiple times with different help hints, after the error message stops being displayed.

@neiljp neiljp added the bug Something isn't working label May 5, 2020
@neiljp
Copy link
Collaborator

neiljp commented May 5, 2020

Also, this doesn't require the last key for me - just wait, and it will update the bottom bar rapidly after the timeout.

@kaustubh-nair
Copy link
Member

@neiljp @preetmishra What is the expected behaviour here?

@preetmishra
Copy link
Member Author

@kaustubh-nair The footer text should only get updated once after the timeout.

@neiljp
Copy link
Collaborator

neiljp commented May 6, 2020

Agreed, this seems fairly obvious from manual testing.

kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 17, 2020
@kaustubh-nair
bugfix: ui: Use a queue to manage footer reset durations.
8dc7787 
Currently, if multiple calls are made to set the footer along with a
duration to reset it (for example, when tries to edit an uneditable
message too often by pressing the key too many times) then it leads to
repeated footer updates because all those calls lead to resetting the
footer. The goal of this commit is to change that, and reset the footer
only once, by ignoring other updates.

A queue is maintained containing number of sleep threads currently
active, and if there are none left then the footer is reset. This
ensures that only the last call to set_footer_text() resets the footer,
thus avoiding multiple resets.

Also, note that it is not strictly necessary to store the duration in
the queue, we could any number we like. However it is kept this way in
case we would like to do more with this in the future, say, spacing out
tight reset calls with only a small duration between them.

Test added.

Fixes zulip#647.
@kaustubh-nair kaustubh-nair mentioned this issue Jul 17, 2020
Closed
kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 17, 2020
@kaustubh-nair
bugfix: ui: Use a queue to manage footer reset durations.
bbdfd8a 
Currently, if multiple calls are made to set the footer along with a
duration to reset it (for example, when tries to edit an uneditable
message too often by pressing the key too many times) then it leads to
repeated footer updates because all those calls lead to resetting the
footer. The goal of this commit is to change that, and reset the footer
only once, by ignoring other updates.

A queue is maintained containing number of sleep threads currently
active, and if there are none left then the footer is reset. This
ensures that only the last call to set_footer_text() resets the footer,
thus avoiding multiple resets.

Also, note that it is not strictly necessary to store the duration in
the queue, we could any number we like. However it is kept this way in
case we would like to do more with this in the future, say, spacing out
tight reset calls with only a small duration between them.

Test added.

Fixes zulip#647.
kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 17, 2020
@kaustubh-nair
bugfix: ui: Use a queue to manage footer reset durations.
3cc2b1c 
Currently, if multiple calls are made to set the footer along with a
duration to reset it (for example, when tries to edit an uneditable
message too often by pressing the key too many times) then it leads to
repeated footer updates because all those calls lead to resetting the
footer. The goal of this commit is to change that, and reset the footer
only once, by ignoring other updates.

A queue is maintained containing number of sleep threads currently
active, and if there are none left then the footer is reset. This
ensures that only the last call to set_footer_text() resets the footer,
thus avoiding multiple resets.

Also, note that it is not strictly necessary to store the duration in
the queue, we could any number we like. However it is kept this way in
case we would like to do more with this in the future, say, spacing out
tight reset calls with only a small duration between them.

Test added.

Fixes zulip#647.
kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 19, 2020
@kaustubh-nair
bugfix: ui: Use a queue to manage footer reset durations.
0cf71c5 
Currently, if multiple calls are made to set the footer along with a
duration to reset it (for example, when tries to edit an uneditable
message too often by pressing the key too many times) then it leads to
repeated footer updates because all those calls lead to resetting the
footer. The goal of this commit is to change that, and reset the footer
only once, by ignoring other updates.

A queue is maintained containing number of sleep threads currently
active, and if there are none left then the footer is reset. This
ensures that only the last call to set_footer_text() resets the footer,
thus avoiding multiple resets.

Also, note that it is not strictly necessary to store the duration in
the queue, we could any number we like. However it is kept this way in
case we would like to do more with this in the future, say, spacing out
tight reset calls with only a small duration between them.

Test added.

Fixes zulip#647.
kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 19, 2020
@kaustubh-nair
bugfix: ui: Use a queue to manage footer reset durations.
2b3f47b 
Currently, if multiple calls are made to set the footer along with a
duration to reset it (for example, when tries to edit an uneditable
message too often by pressing the key too many times) then it leads to
repeated footer updates because all those calls lead to resetting the
footer. The goal of this commit is to change that, and reset the footer
only once, by ignoring other updates.

A queue is maintained containing number of sleep threads currently
active, and if there are none left then the footer is reset. This
ensures that only the last call to set_footer_text() resets the footer,
thus avoiding multiple resets.

Also, note that it is not strictly necessary to store the duration in
the queue, we could any number we like. However it is kept this way in
case we would like to do more with this in the future, say, spacing out
tight reset calls with only a small duration between them.

Test added.

Fixes zulip#647.
kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 28, 2020
@kaustubh-nair
bugfix: ui: Use a queue to manage footer reset durations.
113c495 
Currently, if multiple calls are made to set the footer along with a
duration to reset it (for example, when tries to edit an uneditable
message too often by pressing the key too many times) then it leads to
repeated footer updates because all those calls lead to resetting the
footer. The goal of this commit is to change that, and reset the footer
only once, by ignoring other updates.

A queue is maintained containing number of sleep threads currently
active, and if there are none left then the footer is reset. This
ensures that only the last call to set_footer_text() resets the footer,
thus avoiding multiple resets.

Also, note that it is not strictly necessary to store the duration in
the queue, we could any number we like. However it is kept this way in
case we would like to do more with this in the future, say, spacing out
tight reset calls with only a small duration between them.

Test added.

Fixes zulip#647.
kaustubh-nair added a commit to kaustubh-nair/zulip-terminal that referenced this issue Jul 28, 2020
@kaustubh-nair
bugfix: ui: Do not update footer if new text is same as current.
5c631d9 
This prevents rapid footer updates if an error message is triggered
multiple times. An example of this would be a user holding-down/pressing
too often the edit message key on a message that cannot be edited.

This fix does not account for updates that might happen for different
messages, but we can safely assume that the time difference between such
messages would not be too small and such a bug would most likely not
occur.

Test added.

Fixes zulip#647.
@kaustubh-nair kaustubh-nair mentioned this issue Jul 28, 2020
Merged
neiljp pushed a commit to kaustubh-nair/zulip-terminal that referenced this issue Mar 13, 2022
@kaustubh-nair @neiljp
bugfix: ui: Do not update footer if new text is same as current.
f3d878f 
This prevents rapid footer updates if an error message is triggered
multiple times. An example of this would be a user holding-down/pressing
too often the edit message key on a message that cannot be edited.

This fix does not account for updates that might happen for different
messages, but we can safely assume that the time difference between such
messages would not be too small and such a bug would most likely not
occur.

Test added.

Fixes zulip#647.

Comment & slight adjustment by neiljp.
@neiljp neiljp added this to the Next Release milestone Mar 13, 2022
neiljp pushed a commit that referenced this issue Mar 13, 2022
@kaustubh-nair @neiljp
bugfix: ui: Do not update footer if new text is same as current.
b1235d2 
This prevents rapid footer updates if an error message is triggered
multiple times. An example of this would be a user holding-down/pressing
too often the edit message key on a message that cannot be edited.

This fix does not account for updates that might happen for different
messages, but we can safely assume that the time difference between such
messages would not be too small and such a bug would most likely not
occur.

Test added.

Fixes #647.

Comment & slight adjustment by neiljp.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
0.7.0
3 participants
@neiljp @kaustubh-nair @preetmishra