When the chat messages are shown from newest to oldest and a new message
arrives the list is automatically scrolled to keep the current visible
messages at the same place, except if the list was at the top, in which
case no scrolling is made and the new message appears.
When the chat messages are shown from oldest to newest and a new message
arrives the list is automatically scrolled to show the new message,
except if the list was not at the bottom in which case no scrolling is
made and the current visible messages are kept at the same place.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The header element contains the header div; as the header div uses a
fixed position the header element has no height, so an explicit height
was set for it to prevent "#app-content-wrapper" from overlapping with
the header element. However, as "#app-content-wrapper" has a 100% height
that caused the "#app-content-wrapper" to be moved 45px to the bottom,
and thus the chat view was partially cropped at the bottom.
When the chat view messages are shown from newest to oldest this causes
the first messages to be out of view, but when they are shown from
oldest to newest with the new message input at the bottom then the input
is partially out of view.
Now instead of giving the header an explicit height a "padding-top" is
set for the "#app-content-wrapper"; this prevents the contents from
being cropped while also preventing them from overlapping the header.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the tab contents were larger than the available space they were
limited to that space. Now, if the available space is larger than the
needed height the tab contents is also increased to fill it.
This ensures that the chat view will always stretch to the available
space, which in turn ensures that the "New message" input will be always
shown at the bottom of the sidebar like done in the main view (which was
not the case before when there were no messages or only a few).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before chat messages were shown from newest to oldest, with the new
message input above the list of messages. Now the layout can be chosen,
either the previous one or the reversed one, from oldest to newest with
the new message input below the list of messages.
The new reversed layout is the default one, and probably the old one
will not be used anywhere in the future... but for the time being I kept
the old one too just in case.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Limiting the scroll bar in the sidebar to the list of chat messages
causes the scroll bar to be removed from the whole sidebar in other tabs
too. Therefore, the scroll bars must be explicitly enabled in the other
tab contents that need them.
The list of participants grows dynamically, so a vertical scroll bar
should be enabled on it to be able to view all the participants in a
long list.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The positioning context (the element that an absolute element is
relative to) of the tooltips shown for the date of messages was the
author row, and thus they were visible only were the author row would be
visible. The author row would be clipped outside the list of messages
(due to its "overflow-y" CSS property), so the tooltip shown for the
date of the newest message was clipped at the top of the list of
messages.
Now the tooltips are added to the chat view itself, so "#app-content"
becomes their positioning context and thus are no longer clipped by the
list of messages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In CSS it is not currently possible to select an element based on
whether it has certain child or not, nor select the parent element of
another one. In certain cases it may be necessary to use a special style
for the tab content wrapper element, for example to remove the padding
from the wrapper and left the tab content element itself to handle it.
To support that now the tab content wrapper has the "tab-{tabId}" CSS
class in addition to the "tab" CSS class.
Another option would have been to make possible to specify the class
name to use when a tab was added so the same class could be used by the
wrapper when showing different tabs. However this seem like an uncommon
use case, and there should not be a lot of tabs anyway, so the current
approach would not require a lot of ".tab-{tabId1}", ".tab-{tabId2}",
".tab-{tabId3}"... selectors for the same rules in the CSS files anyway.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The class was copied from the markup of the server sidebar, but it is
not used anywhere and its name is misleading now that the scroll bar is
shown on the tabs that need it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Except when almost empty, the message list of the chat view is taller
than its available vertical space in the sidebar. Due to this a scroll
bar was shown for the whole sidebar, and everything was moved when
scrolling to see overflown messages. Now the scroll bar is shown only
for the message list, so it can be scrolled without moving the other
elements in the sidebar.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The value of the input was not properly updated when the model attribute
changed. Instead of updating it in that case too now it is always
updated before the input element is shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Some browsers (like Firefox) automatically return the focus to the new
message input after sending a message, while others (like Chromium) do
not. Now the focus is explicitly given back to the new message input to
make more comfortable to keep writing new messages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Jan-Christoph Borchardt
Daniel Calviño Sánchez
Ivan Sein
Nextcloud bot