Bug #6562
closedWPopupMenu - Submenus seem broken to me
0%
Description
We switched our application from Wt3 to Wt4 this month and we noticed a problem with WPopupMenu's that contain submenu(s).
I tested it with v4.0.3 and v4.0.4. I tried Firefox(61.0.2) and Chrome(68.0.3440.106).
The attached example contains two uses of WPopupMenu with a submenu.
Example 1
This example is simplification of how we use the WPopupMenu in our application.
- On clicking the right button and selecting "Item 3" the first time the submenu shows up twice, also notice the three horizontal dots in the place where the submenu should be
- Change the selection to any other menuitem without closing the popupmenu, all submenus close, the dots remain
- Change the selection back to "Item 3", the submenu is visible again "Sub Item 1" + "Sub Item 2" are selectable
- On closing the popupmenu the dots remains, this can be repeated everytime you open the popupmenu new and select "Item 3"
In our application the behaviour is slightly different, on 1. the submenu is not visible at all, only the dots show instead.
Example 2
I could not figure out what is wrong with the first example so I tried the example from [[[https://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WPopupMenu.html#details]]]
I am not sure if it is supposed to be a working example but here is what happens if you run it:
- On clicking the left button and selecting "Item 3" the first time the submenu shows up twice
- Change the selection to any other menuitem without closing the popupmenu, the extra submenu vanishes
- Change the selection back to "Item 3", the submenu is visible but "Sub Item 1" + "Sub Item 2" are not selectable
- On closing the popupmenu the submenu remains, this can be repeated everytime you open the popupmenu new and select "Item 3"
I also tried running the example from the widget gallery: [[[https://webtoolkit.eu/widgets/navigation/popup-menu]]]
It shows the same problem as example 2, but the difference is the WPopupMenu is only created once and then reused.
So after closing and opening it again it starts to work normal.
It is really likely I do something very wrong, but I cant find it.
I welcome any help with the issue.
Files
Updated by Roel Standaert about 6 years ago
- Target version changed from 4.0.4 to 4.0.5
Updated by Roel Standaert about 6 years ago
- Tracker changed from Support to Bug
- Status changed from New to Resolved
Looks like the problem is that the sub-WPopupMenu has two parents, where it actually should only have one: the menu item it belongs to.
There appears to be some other issue, though: in the default theme, the submenu stays behind if you click on the menu item that opens it, or one of the submenu's menu items.
Updated by Roel Standaert about 6 years ago
Seems like that last issue affects Wt 3, too, and it's it's not related to the theme. The submenu doesn't close when the menu items have no action associated with them.
Updated by Markus S about 6 years ago
Roel Standaert wrote:
Seems like that last issue affects Wt 3, too, and it's it's not related to the theme. The submenu doesn't close when the menu items have no action associated with them.
Thank you for your quick response!
I just tested the fix with my application and the strange dots are gone.
But I can see now the left over submenus instead of the dots if I close the menu by clicking the menuItem that opened the submenu, like you described.
What do you mean by:
The submenu doesn't close when the menu items have no action associated with them.
Does it mean nothing is connected to the trigger signal?
Because it sounds like adding a dummy-action could be a valid workaround for me then.
Updated by Roel Standaert about 6 years ago
Does it mean nothing is connected to the trigger signal?
Yes, if you look at the widgetgallery example here: https://www.webtoolkit.eu/widgets/navigation/popup-menu, then you'll notice that the submenu disappears when clicking one of the items.
I've already bisected the issue to a commit somewhere between Wt 3.3.4 and 3.3.5, so it's been an issue for quite a while already.
Updated by Markus S about 6 years ago
Thats interesting.
I just tried the workaround by giving the MenuItem that opens the submenu a dummy action(triggered().connect( []( Wt::WMenuItem* x ){ } );).
But this does not change the outcome, the opened submenu remains.
Usually we dont use triggered for the MenuItems anywhere, we open the WPopupMenu with exec() which returns the selected MenuItem, the customized MenuItem has the action that we invoke.
In my opinioneverything should be closed after exec() returned something.
I see that [[[https://www.webtoolkit.eu/widgets/navigation/popup-menu]]] is working, but the MenuItem that opens the submenu has nothing connected to triggered unless I am mistaken.
I will try this again tomorrow with simplified examples to understand why what works.
Updated by Markus S about 6 years ago
I did some testing and understand now why we did not notice this issue in Wt3.
With Wt3 we created the WPopupMenu's on the heap and they did not get destroyed after exec().
They only got deleted on exiting the session. But it worked, no remaining submenus.
With Wt4 we delete the parent WPopupMenu after the exec() call.
I backported the example to wt3 and if I dont delete the PopupMenu after exec() both Wt3 and Wt4 behave the same way.
The submenu gets closed most of the time, but sometimes it just remains and moves to the topleft corner of the page.
For lucky reasons I dont completely understand the remaining submenus never where visible in our application, yet I am sure they got left behind as well.
Deleting the PopupMenu in Wt4 changes the bug slightly, the submenu remains visible where it opened and this is why we noticed it.
Updated by Markus S about 6 years ago
The example at [[[https://www.webtoolkit.eu/widgets/navigation/popup-menu]]] is easy to break as well, just set the MenuItem that opens the submenu selectable.
But if the bug does not trigger the first time you need to reload the page(PopupMenu is never destroyed, just reopened), but if it triggers then the submenu will also remain in the top/left.
I've already bisected the issue to a commit somewhere between Wt 3.3.4 and 3.3.5, so it's been an issue for quite a while already.
So I agree this is an old bug, but should I open a new ticket since this ticket is "resolved" or is there already a old ticket for this?
Updated by Roel Standaert about 6 years ago
Yes, I was thinking of making a new issue for that, but if you can do it before I get around to that, that's fine as well :-).
WMenu.C has a comment:
TODO:
- disable everything selection-related for menu items that have a popup menu
So I'm thinking that maybe enabling selection for items that have a popup menu was never supposed to be possible?
Updated by Roel Standaert almost 6 years ago
- Status changed from Resolved to Closed