Closed webcliq closed 3 years ago
My pleasure ... Well, although I don't seem to have the same problem in the same extent I can understand your issue.
Currently the contextmenu closes on a mouseleave
event. So when the very first movement of the mouse is either up- or leftwards the contextmenu closes in some browsers and in others it does not close. I see that's not ideal and there several ways to "fix" it. Maybe it's a good solution to remove the handler for the mouseleave
event completely. Then the contextmenu would close only upon a click in the document outside of the contextmenu and you could , if needed, add a handler to the items in your menu closing the panel on click for example. In addition this behaviour would more or less be the same like the browser's own contextmenu's behaviour.
What do you think?
I agree with your suggestion. Definitely remove the mouseleave event.
To add a close call to a contextmenu item click is straightforward and better. This leaves the requirement to close the contextmenu when a cmenu item is not instantiated.
I think that I will add a cancel item to my cmenu. Clicking outside the cmenu should close it Finally an Esc key press/touch should close it
Finally, add an option to the Contextmenu extension to make an selection between the current situation (mouseleave) and no mouseleave. That suits everyone.
I updated the contextmenu extension with an additional parameter closeOnMouseleave
to make the close on mouseleave optional. It defaults to true in order not to affect existing code. Close on click in document worked anyhow already.
Check out example 1 of the demo.
Download updated files here.
Let me know how it works out ...
Update: the regular option closeOnEscape works with contextmenus anyhow.
@webcliq Hi there... I would really appriciate some feedback! Regards, Stefan
I was under the impression that I had replied but apparently this is not so. In that case please accept my apologies. It is indeed rude of me not to reply.
Thank you for the modification. As a result of the modification and in my situation, the contextmenu now works perfectly and exactly as I would wish.
Thank you and keep safe ....
Firstly thanks for help on overlapping and stepping the panels. I have adopted your suggestions.
You will be aware from the screenshot I sent you how the base or first panel will invariably be a data table or data listing component. To avoid having CRUD icons or a menu button on each row (or equivalent), I have always used a Contextmenu component. For years this has been one or other third party component. However in a continuing effort to standardise and normalise the Code, I decided to utilise jsPanel contextmenu component for this project.
However I have a problem ... which shows itself equally on your demo as it does on my system. The facility to autoclose the context menu is too sensitive. That is, on average, when one moves the cursor (with the mouse) from the point of initiation of the menu with a right click to the required item on the menu, the menu closes before the cursor has reached the menu item. Obviously this is because from the point of view of extension javascript, the pointer has "strayed" outside of the menu div and this triggers a close.
The fact the menu closes in say 4 out of 5 attempts to move from initiation to item selection is annoying and a problem to any user. jQuery has an extension called "hoverIntent" by Brian Cherne (on Github)) which in earlier days would solve this problem. Now that you have removed reliance on jQuery I am not certain of right route forward but something like hoverIntent is needed.