Just something to put my mind at rest. I’ve just added a modal menu for mobile only. All well and good. However I’ve noticed in mobile preview in Header editor that the Ubermenu menu, although not visible, links are clickable. Is this a known issue of the editor preview? I don’t want customers accidentally tapping their screens only to find they are mysteriously going to a page they didn’t want to go to!
Website here:
https://poole.stadia.uk/
…and modal nav is set for < 767px. I’m viewing on PC. If this is the same on mobile the modal navigation is unusable. Surely has to be set to display:none by jquery so the links are completely removed??
Hello There,
Thanks for writing in! I am not seeing the modal toggle in desktop screens. This is only meant for smaller screens. Regretfully, at this time I am not entirely certain what it is you would like to accomplish based on the information given in your post. If you wouldn’t mind providing us with a little more clarification on what it is you’re wanting to do (a link to a similar example site would be very helpful, or perhaps some screenshots), we’ll be happy to provide you with a response once we have a better understanding of the situation.
Thanks.
It is perfectly simple what I am saying. I have tested on both iphone and android. And the client has complained. In it’s current form the modal navigation is unusable.
On mobile. Or on desktop with width reduced. Load up any page. Click anywhere where there is no link eg around the main logo. The transparent modal menu links that shouldn’t be there take you to pages you don’t want to go to. Scroll down on the ‘news’ page, try to click a link and it takes you to what ever link you press on the transparent modal menu.
As I originally stated, the modal menu is not being removed eg. by using display: none; , once the opacity is reduced to zero so even though you can’t see the modal menu you can still click on the links.
I have no time to wait for updates if you choose to fix this. I’m disappointed you didn’t investigate my initial enquiry properly by simply viewing the said site on a mobile. And perhaps checking the modal navigation on a mobile in the first place. The problem is plain to see - the joke being the problem is (visibility:)hidden.
I have (temporarily) fixed the issue by putting custom css code in the customizer:
/* FIX FOR MODAL WINDOW */
.x-modal {display:none;}
.x-modal.x-active {display:initial;}
I didn’t want to tinker with the theme code for obvious reasons (ie future updates) so unfortunately the ‘fix’ does away with the modal fade.
Thanks for writing in and I’m sorry that you seem to be having some issues here. This is not an issue with the modal per se, and instead has to do with some problematic styles generated by UberMenu.
Our modal element that we’ve created (.x-modal and all of its child elements) is setup to be visually hidden and non-interactive by default using these styles (additional styles are removed for clarity):
.x-modal {
visibility: hidden;
pointer-events: none;
}
Then, when the modal is in its active state, these change:
.x-modal.x-active {
visibility: visible;
pointer-events: auto;
}
The reason these were picked is because visibility is an animatable CSS property, meaning that it can have transitions applied to it (including transition delays and durations), wherease display cannot. The goal of Pro’s modals was to create something that relied on CSS as much as possible without any unnecessary or heavy JavaScript. Basically, when a modal is toggled, the only JavaScript that runs is the adding/removing of the x-active class to the modal itself, and the CSS handles the rest. While the opacity is transitioned smoothly as it is a visible effect, the visiblity is delayed when the x-active class is removed so that there isn’t a hard removal of the modal, creating an overall cleaner effect. visibility: hidden paired with pointer-events: none on the non-active state is enough be default to keep these items from being interacted with. You will notice if you use our native modal menu in this section that you cannot interact with any of these links when the modal itself is not visible.
The issue for your situation lies with UberMenu. For whatever reason, they have decided to apply pointer-events: auto to a whole slew of selectors right off the bat:
.ubermenu,
.ubermenu .ubermenu-column,
.ubermenu .ubermenu-divider,
.ubermenu .ubermenu-icon,
.ubermenu .ubermenu-image,
.ubermenu .ubermenu-item,
.ubermenu .ubermenu-nav,
.ubermenu .ubermenu-retractor,
.ubermenu .ubermenu-row,
.ubermenu .ubermenu-search,
.ubermenu .ubermenu-search-input,
.ubermenu .ubermenu-search-submit,
.ubermenu .ubermenu-submenu,
.ubermenu .ubermenu-submenu-footer,
.ubermenu .ubermenu-tabs,
.ubermenu .ubermenu-tabs-panels,
.ubermenu .ubermenu-target,
.ubermenu-responsive-toggle {
...
}
While I’m sure they have their reasons, the issue lies here. Unlike opacity where if a parent has opacity: 0 a child cannot have opacity: 1 and be visible, pointer-events can have different values at each level of child. So even though our modal by default hides all interactions with native X components and makes them non-interactive by applying pointer-events: none to the modal when it isn’t active, since UberMenu is overwriting that with their own styles, this is why you are still able to interact with UberMenu’s menu in this situation, not our own code.
Due to the fact that UberMenu does this, for the time being if you wish to continue using UberMenu in a modal, your additional display CSS styles will need to be in place to overwrite UberMenu’s children from being interactive. We will certainly take this situation into consideration and see about updating the modal to include an inline style of display: block and display: none on certain actions to further assist for situations like this that our outside of our control.
Hopefully this helps to shed more light on the situation.
Excellent explanation. Thank you. I would go ‘native’ but for the lack of sub-menu. Unless I’m doing something wrong! I was going to tweak the script but thought it foolhardy what with updates and all. As would be tweaking Ubermenu. I hope you manage to liaise with them. But as you suggest they must have their reasons, rightly or wrongly. I can’t see any workaround except the blunt tool that is display in pure CSS use. I’ll look out for updates. Thanks again.
No problem at all, happy to help provide a little more context to this unique situation. At this time, the modal navigation does not have a mechanism for viewing submenus, but we do have some ideas for this and plans to improve it going forward. I do have an idea for this particular situation that we may be able to get into the modal at a core level without too much overhauling. I have made a note for this in our GitHub account so it is tracked and we will keep up with it there. Any updates on it in the future can be found in our changelog along with all of our other notes online.
Cheers!
1 Like
Me being thick. Of course there was a solution. Amazing what 6 hours sleep does - too much ‘Joe’ and too many Twin Peaks episodes (is that even possible for this child of the early 70s??!) I’m supposed to be on holiday! Pasting this into Ubermenu’s “Custom CSS Tweaks - Mobile”, making sure the two breaking points tally, obviously works:
.x-modal .ubermenu,
.x-modal .ubermenu .ubermenu-column,
.x-modal .ubermenu .ubermenu-divider,
.x-modal .ubermenu .ubermenu-icon,
.x-modal .ubermenu .ubermenu-image,
.x-modal .ubermenu .ubermenu-item,
.x-modal .ubermenu .ubermenu-nav,
.x-modal .ubermenu .ubermenu-retractor,
.x-modal .ubermenu .ubermenu-row,
.x-modal .ubermenu .ubermenu-search,
.x-modal .ubermenu .ubermenu-search-input,
.x-modal .ubermenu .ubermenu-search-submit,
.x-modal .ubermenu .ubermenu-submenu,
.x-modal .ubermenu .ubermenu-submenu-footer,
.x-modal .ubermenu .ubermenu-tabs,
.x-modal .ubermenu .ubermenu-tabs-panels,
.x-modal .ubermenu .ubermenu-target,
.x-modal .ubermenu-responsive-toggle {
pointer-events: none;
}
.x-modal.x-active .ubermenu,
.x-modal.x-active .ubermenu .ubermenu-column,
.x-modal.x-active .ubermenu .ubermenu-divider,
.x-modal.x-active .ubermenu .ubermenu-icon,
.x-modal.x-active .ubermenu .ubermenu-item,
.x-modal.x-active .ubermenu .ubermenu-nav,
.x-modal.x-active .ubermenu .ubermenu-retractor,
.x-modal.x-active .ubermenu .ubermenu-row,
.x-modal.x-active .ubermenu .ubermenu-search,
.x-modal.x-active .ubermenu .ubermenu-search-input,
.x-modal.x-active .ubermenu .ubermenu-search-submit,
.x-modal.x-active .ubermenu .ubermenu-submenu,
.x-modal.x-active .ubermenu .ubermenu-submenu-footer,
.x-modal.x-active .ubermenu .ubermenu-tabs,
.x-modal.x-active .ubermenu .ubermenu-tabs-panels,
.x-modal.x-active .ubermenu .ubermenu-target,
.x-modal.x-active .ubermenu-responsive-toggle,
.x-modal.x-active .ubermenu .ubermenu-image {
pointer-events: auto;
}
Thank you for for your help in making a satisfactory solution. I can’t see why Ubermenu’s developers have even used pointer-events the way they have unless they believe the “pointer-events” demon is out to get their menu but where there’s a will, there’s a way 
C’est la vie! I’m off to the pool; the sun waits for no man!
Cheers, Kia
Thank you for letting us know!
Hey @stadiauk9999, that’s a great interim solution for the time being. I’ve edited your snippet a little bit so other users might be able to see what’s going on more clearly. Ultimately we hope to have this addressed natively with some inline JavaScript on the modal itself as mentioned previously, but this will certainly help for now and allow you to keep the modal transition. Thanks for sharing!