-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Clicking on the contents may not close the menu in the sharing page #7613
Comments
I'd just like to note that a very recent bug report to the Deck app was to restore (or add an optionto enable) right sidebar that doesn't close when losing focus... |
The issue applies too to the contacts and settings menu, as they use the same technique of listening to the
I agree that a sidebar should not be closed when losing focus, but this issue is about menus, not sidebars; unrelated behaviours in my opinion ;-) |
Fixed with #15719 |
This it not fixed with #15719, because this issue is about the menu in the header of the public share page, not the menu in the Sharing tab of the Files app sidebar. |
Then I did not understood the issue :) |
☝️ also, screenshots make things easy to understand. :) |
Hi, please update to 24.0.8 or better 25.0.2 and report back if it fixes the issue. Thank you! |
In the sharing page (go to the Files app, open the right sidebar for a file, open the Sharing tab, click on Share link and open that link in the browser) the share menu is open when clicking on the toggle at the right of the header, and once open it is closed when clicking anywhere outside the menu (in current master clicking again on the toggle does not close the menu, but there is a fix for that in #7598).
That is the theory, though. In practice, depending on the app contents, the menu may or may not be closed when clicking on them. The reason is that the menu is closed when a
mouseup
event is received by the document and that event originated on an element which is not the share menu. However, if the propagation of themouseup
event was prevented in any descendant element it would not bubble all the way up to the document, the handler would not be executed and the menu would not be closed. This happens, for example, when using the PDF Viewer app and opening a sharing page for a PDF file.This could be solved by using a different technique to close the menu: when the menu is open a transparent div covering the whole page is created, and when a click is received on that div it is removed and the menu is closed. The
z-index
of the div should be higher than any other element in the page, except for the share menu (and the toggle, to support the changes from #7598).There is a problem in that approach, though. Currently when clicking outside the share menu the click is handled by the element visually receiving it (and its ancestors), and this will also close the menu. However, if a div is covering the whole page then the div (and its ancestors, but that is not very relevant) will handle the click, but not the element visually receiving it. The result is that the menu will be closed, but nothing will happen with the element that the user thinks she is clicking on.
It would be possible to solve that too by generating a new click event and sending it to the element that should have been clicked (by using something like elementFromPoint once the div is removed)... but it feels like a hack more than a solution, and to be honest I do not know if that would work in every situation.
If there is a proper solution to that problem I am afraid that I do not know it. Ideas (and, better yet, patches ;-) ) welcome :-)
So, when the share menu is open, which one is the best option?:
@nextcloud/designers
The text was updated successfully, but these errors were encountered: