If the server is too slow, changing to a different file immediately
after sending a new comment but without waiting for the comment to be
shown for the original file could cause the new comment to be shown for
the current file instead.
This is, indeed, a bug in the comments. However, it is not possible to
test it reliably in the acceptance tests, as it depends on how fast the
server adds the message and how fast the client changes to a different
file; sometimes the test would fail and sometimes it would not.
Therefore, now it is waited for the comment to be added before changing
to another file, as in this case it can be reliably tested that changing
to a different file does not cause the comments from the previous file
to be shown in the current file (this was a different bug already fixed
and due to which this test was added in the first place).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "Comments" tab is open the empty content element is always in
the DOM, although it is only shown once the message collection was
fetched and there were no messages. Due to this it is necessary to
explicitly wait for it to be shown instead of relying on the implicit
wait made to find the element; otherwise it would be found immediately
and if the collection was not fetched yet it would not be visible,
causing the test to fail.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Navigating to the root folder is already handled by
OCA.Files.Navigation.setActiveItem in case the view doesn't change.
Signed-off-by: Julius Härtl <jus@bitgrid.net>
When a view is rendered it should not be concerned with where it is
going to be placed in the document; in general this should be a
responsibility of the object using the view.
Moreover, when the details view is rendered it should simply prepare a
skeleton that includes the root elements provided by the plugins; those
elements will be updated by the plugins as needed when a file or a tab
is selected.
Finally, the details view should not be explicitly rendered. The
rendering removes the previous elements, but that is needed only when
the details view is in a dirty state, that is, when new plugins were
added since the last time that it was rendered. However, that dirty
state is internally handled, and the view is automatically rendered
again if needed when a file info is set.
Due to all that the details view is no longer explicitly rendered when
updating it with a different file. Also, as each file list has its own
details view, and each details view has its own element, but there can
be only one details view/sidebar element in the document, when the file
list updates the details view it also replaces the current one in the
document with its own details view if needed (that is, if it is not the
current one already).
Besides that, when the element of a details view is replaced with the
element of a different details view the old one should be detached from
the document, but never removed. Otherwise the event handlers would not
work when that element is attached again later (when changing to a
different section in the Files app and then going back to the previous
one).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Tab headers that should not be shown are marked with the "hidden" CSS
class. The CSS rules set "display: none" for ".hidden" elements, but as
the rules for ".tabHeaders .tabHeader" are more specific than rules for
".hidden" the "display" property is overriden and ends being "flex".
Therefore, it is necessary to explicitly set a rule for ".tabHeaders
.tabHeader.hidden" elements.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Kesselberg
Daniel Calviño Sánchez
Roeland Jago Douma
Nextcloud bot
Morris Jobke
Robin Appelman
Patrick Baber
Julius Härtl
John Molakvoæ (skjnldsv)
Christoph Wurst
Sylvia van Os
John Molakvoæ
Jan-Christoph Borchardt
Roeland Jago Douma