Firefox handling of nested MenuItems

[reryro]

I have a question about the operation of MenuItem -- specifically, nested MenuItems, i.e., MenuItems appended to another MenuItem. This pertains to Firefox only: When using a mouse to navigate the screen it works fine -- as soon as you point to the upper level item, the nested list of items appear and you can then select the desired one. However, in a touch-screen environment, the user has to know to touch and hold for the sub-items to appear -- nothing happens if you simply touch, or even worse -- the item above or below your desired one is activated (assuming they have no nested submenu). So, my question is, is there some browser-specific meta data that can be sent to Firefox to tell it to activate the submenu with just a touch instead of touch and hold?

[dddomodossola]

Hello @reryro , I pushed a fix to the master branch. Can you please give it a try and eventually close the issue?
Now MenuItems open with mouse click instead that mouse hover event. This allows a better user interaction.

[reryro]

Hello @reryro , I pushed a fix to the master branch. Can you please give it a try and eventually close the issue? Now MenuItems open with mouse click instead that mouse hover event. This allows a better user interaction.

Davide, thanks so much for this; it worked for me just as you described. I have two questions, if you don't mind...

After I installed your updated code, I couldn't see any change in the browser, even though I had rebooted the server, closed and reopened the browser, cleared the browser cache, restarted the app again -- nothing worked until I changed the port number in my code to force Chrome to see this as a new site -- only then did I see the new behavior of the menu. What did I miss? What is necessary to get new Remi code to take effect in the browser?

And secondly, when I select a menu item, whether it's nested or not, the drop-down menu stays visible on the screen -- I'm sure I'm supposed to do something to close the menu at this point but I'm not sure what that is. How do you close the menu when the selection has been made?

[dddomodossola]

Hello @reryro ,
As you correctly did, it is only required to refresh the cache to make it working. I know that you cleared the browser cache and got no effect, but there is nothing magic, it had to work. I only changed 3 css lines and an html attribute.

Previously the menu item was closing by moving out the mouse cursor. Now it is required to lost the focus. So, to make the menu to close you need to click outside the menu. I will do further tests about this, thank you for reporting.

[reryro]

Yeah, I don't know what happened with the data refresh; it didn't make any sense to me, either.

As for the menu disappearing upon selection, in my app, music play functions are activated by various menu selections, so no further screen changes occur. Since it really doesn't make sense to require the user to click again to clear the menu, what would you suggest would be the best way to simulate a click programmatically, as part of the selection processing?

[dddomodossola]

@reryro I have to distinguish a click to a leaf menu item instead of a click to a menu item that has children. When clicking on a leaf, the menu should close. This could be a solution, doesn't it?
I should be able to make this in the weekend.

[reryro]

"This could be a solution, doesn't it?" I would have to withhold judgment until I see the result. In my mind, it seems that a menu should fire an event and close. If the menu element has children, then their listener would redisplay the menu (to their level) until their onclick event fires. I'm sure I'm over-simplifying, but that seems to be how I've seen menus behave in the wild. Do you see it differently?

…

On Tue, Nov 2, 2021, 3:52 PM Davide Rosa ***@***.***> wrote: @reryro <https://github.com/reryro> I have to distinguish a click to a leaf menu item instead of a click to a menu item that has children. When clicking on a leaf, the menu should close. This could be a solution, doesn't it? I should be able to make this in the weekend. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#469 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFC4OPWEVN46AGIISMPOXODUKBTTPANCNFSM5GRSAFEA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dddomodossola]

@reryro Now should be fixed, thanks for the patience. If you can, please give it a try and let me know your opinion.

[reryro]

I'm across the country from my PC and Pi until next week -- I will check then & will be sure to let you know. Thanks!