Closed vitosamson closed 2 years ago
I don't think this solution is resilient enough. For example, what if we have a <textarea>
in the offcanvas menu? What if we have a <select>
? The default use case for offcanvas is for menus. If you're using it for something else, you may be better served by creating a custom directive that swallows up click events.
Is it so uncommon to have a search field in a menu though? My example use case is using the off-canvas to replace a topnav on mobile. The Zurb Foundation docs site has their search field in the menu (though it's not off-canvas, it's still a menu).
What do you think of checking if the clicked element has an attribute, like prevent-close="true"
, before closing the menu? I feel like creating a directive that swallows up the event could have unintended consequences with anything else that might be listening for clicks on the input element.
Even by modifying the click event to avoid closing if element is a input, on a mobile when the keyboard appears the menu is closed... An idea to prevent this behavior?
Here's my solution:
Change this:
$scope.hide = function () {
sidebar.removeClass('move-left');
sidebar.removeClass('move-right');
};
By:
$scope.hide = function (e) {
if (typeof(e) == "undefined") {
sidebar.removeClass('move-left');
sidebar.removeClass('move-right');
}
};
Currently including an input in the offcanvas menu is impossible, as clicking on any element in the menu closes it. This PR makes sure the click event target is not an input element before triggering the menu to close.