Long reply covers previous messages #16038
Labels
Comments
|
Hello @zulip/server-compose members, this issue was labeled with the "area: compose" label, so you may want to check it out! |
|
Maybe the right answer is to have the maximum compose box height be at most bottom_whitespace? (And then we can tune those values, but that seems like the logical structure needed to resolve this?) |
|
@zulipbot claim |
|
Welcome to Zulip, @aryanshridhar! We just sent you an invite to collaborate on this repository at https://github.com/zulip/zulip/invitations. Please accept this invite in order to claim this issue and begin a fun, rewarding experience contributing to Zulip! Here's some tips to get you off to a good start:
As you work on this issue, you'll also want to refer to the Zulip code contribution guide, as well as the rest of the developer documentation on that site. See you on the other side (that is, the pull request side)! |
|
Hello @aryanshridhar, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days. You can reclaim this issue or claim any other issue by commenting Thanks for your contributions, and hope to see you again soon! |
aryanshridhar
added a commit
to aryanshridhar/zulip
that referenced
this issue
Sep 22, 2020
While writing long messages,the textarea would cover-up the latest messages hence blocking its visibility . Fixed this by adding a max-height property to textarea , hence avoiding overlapping with the latest messages in the current stream. Fixes zulip#16038
aryanshridhar
added a commit
to aryanshridhar/zulip
that referenced
this issue
Sep 22, 2020
While writing long messages,the textarea would cover-up the latest messages hence blocking its visibility . Fixed this by adding a max-height property to textarea , hence avoiding overlapping with the latest messages in the current stream. Fixes zulip#16038
garg3133
added a commit
to garg3133/zulip
that referenced
this issue
Jan 18, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `compose-container` is always equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
garg3133
added a commit
to garg3133/zulip
that referenced
this issue
Jan 21, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `compose-container` is always equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened according to then `bottom_whitespace_height`. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
|
Hello @garg3133, you claimed this issue to work on it, but this issue and any referenced pull requests haven't been updated for 10 days. Are you still working on this issue? If so, please update this issue by leaving a comment on this issue to let me know that you're still working on it. Otherwise, I'll automatically remove you from this issue in 4 days. If you've decided to work on something else, simply comment Thank you for your valuable contributions to Zulip! |
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Mar 17, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
|
I have added the fix of this issue in PR #17667 and working on top of it. |
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Mar 26, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Mar 26, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Mar 26, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
garg3133
added a commit
to garg3133/zulip
that referenced
this issue
Mar 27, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `compose-container` is always equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened according to then `bottom_whitespace_height`. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
garg3133
added a commit
to garg3133/zulip
that referenced
this issue
Mar 27, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `compose-container` is always equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened according to then `bottom_whitespace_height`. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
garg3133
added a commit
to garg3133/zulip
that referenced
this issue
Mar 29, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `#compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `#compose` is always less than or equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `#compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened according to the value of `bottom_whitespace_height` at that time. Thus, if the compose-box is already open at the time of bottom-whitespace resize, the max-height of `#compose-textarea` will also get reset at the same time, whereas, if the compose-box is closed at the time of bottom-whitespace resize, the max-height of `#compose-textarea` won't get reset at that time, but it will surely get reset whenever the user will open the compose-box. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Mar 31, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
garg3133
added a commit
to garg3133/zulip
that referenced
this issue
Apr 3, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `#compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `#compose` is always less than or equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `#compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened according to the value of `bottom_whitespace_height` at that time. Thus, if the compose-box is already open at the time of bottom-whitespace resize, the max-height of `#compose-textarea` will also get reset at the same time, whereas, if the compose-box is closed at the time of bottom-whitespace resize, the max-height of `#compose-textarea` won't get reset at that time, but it will surely get reset whenever the user will open the compose-box. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Apr 7, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Apr 13, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Apr 14, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
May 16, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
Signior-X
added a commit
to Signior-X/zulip
that referenced
this issue
Jun 15, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
timabbott
pushed a commit
to Signior-X/zulip
that referenced
this issue
Jun 26, 2021
This commit change the max-height for new_message_textarea to calc(50vh - 50px) in which 50vh will ensure at most half of the viewport is taken by the compose box at max and the 50px is for the top header that we have. This way, there will always be ample amount of space even in small devices so that they can scroll. Part of zulip#17660 Fixes zulip#16038
7 tasks
MSurfer20
pushed a commit
to MSurfer20/zulip
that referenced
this issue
Jul 2, 2021
While writing a long message in compose-box, the last few messages of the current stream gets covered by the compose-box and it gets pretty annoying sometimes trying to figure out a way to read the last message of the stream while writing. Right now, the only way to get past this is to resize `compose-textarea` by using the resize tool at the bottom-right corner of the `compose-textarea`. But, that small resize tool is not always readily visible to the user. The proposed solution in this commit is to reset the `max-height` property of `#compose-textarea` everytime `bottom_whitespace_height` is resized such that the total height of `#compose` is always less than or equal to the height of `bottom_whitespace_height`. Doing this, the compose-box never covers the last message of the current stream. The only problem with this is that if the compose-box is closed at the time of bottom-whitespace resize, we cannot find the `compose_non_textarea_height` and so, we cannot reset the max-height of `#compose-textarea`. To solve this, max-height of `compose-textarea` is also reset everytime a new compose-box is opened according to the value of `bottom_whitespace_height` at that time. Thus, if the compose-box is already open at the time of bottom-whitespace resize, the max-height of `#compose-textarea` will also get reset at the same time, whereas, if the compose-box is closed at the time of bottom-whitespace resize, the max-height of `#compose-textarea` won't get reset at that time, but it will surely get reset whenever the user will open the compose-box. Tested on my Ubuntu Development Environment on Chrome and Firefox browsers. Fixes: zulip#16038.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When typing a long reply, or manually resizing the compose box, if the window is not high enough, the compose frame covers the last messages shown and it's not possible to scroll down and see them, except by resizing the compose box. This at least in the desktop app (snap).
CZO topic: https://chat.zulip.org/#narrow/stream/9-issues/topic/Long.20reply.20covers.20previous.20messages
The text was updated successfully, but these errors were encountered: