Clicking on the contents may not close the menu in the sharing page #7613

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 the mouseup 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?:

• Always handle clicks on the app contents, but depending on what is shown in them the menu is closed or not (current behaviour)
• Never handle clicks on the app contents, but always close the menu (to be implemented)
• Always handle clicks on the app contents, and always close the menu (to be implemented; hacky, may give headaches)
• Always handle clicks on the app contents, and always close the menu (to be implemented; nice, clean and robust... and I do not know how to do it :-) )

@nextcloud/designers