Clarification. I just had a thought… I’m mostly focused on developing for Android and don’t really test on the iOS markup much. So… I tested it, and the iOS markup behaves as the documentation says it should. Checking the checkbox inside a list item doesn’t cause the ripple to activate… but it DOES cause it to activate when in Android mode…

As I understand the documentation, the checkbox and buttons, when inside a list item, shouldn’t cause a list item ripple when clicked. The button doesn’t… Which is good. But the checkbox, when clicked or tapped, causes the list item to ripple. Is there something I can do?

So perhaps I am doing something wrong. I am observing that eventListeners are piling up. Here is my situation. I tap a button, which causes a pushPage to occur. In the new page, add an eventListener. Later, the page gets popped. If I pushPage to the page again, an additional eventListener is created. The old event listener isn’t removed when a page is removed from the DOM. I see this using Chrome Dev tools. My question: should Onsen do this for me, or am I expected to manage this myself?

Is it possible to “scroll” to an item that has been removed from the DOM due to the lazy system? Or, more specifically, in my case, I might add an item to the data set that feeds the lazy list, but due to what part of the list I am viewing, the added item may not appear in the DOM after a lazy.refresh. I would like to progmatically “scroll” to a specific item that I just added, even if that item isn’t in the DOM. The reason: when an item is added, I want to view the list so that I can see and flash the list item that was just added to the data. It would be neat if there was a method such as .goto(index). From what I can tell, there is not.

So, I ended up just doing a little hack to adjust the minimum height of the popover. Taken from my css mod file:

/* onsen-ui normally sets this at 100px.  that means you can't have a popup menu of just one list-item.  this change fixes that. */
.popover__content{
	min-height: 				0px;
}

Works for me.

Hi. I have the following code. It is a popover that covers a “md-more” toolbar button. It only has one list-item, but the popover seems to require two at a minimum and forces spaces for two. Please see screenshot for example output. I am using Onsen 2.8.3, but I’m not ready to upgrade at this point, so I don’t know if it’s still an issue or not.

<ons-popover ... cover-target cancelable>
	<ons-list>
		<ons-list-item tappable>
			Delete
		</ons-list-item>
	</ons-list>
</ons-popover>

Hello,

Maybe I’m missing something, but how can I change the GestureDetector’s holdTimeout property without editing the onsenui.js file?

If I understand the problem, I also have a situation like this. My login screen doesn’t need the splitter menu. But it doesn’t need a toolbar either. I first played with just removing swipeable, but later decided to keep my login page simple, and use “window.location = file.html” instead to go to the main page that has the splitter and everything.

@Fran-Diox I agree, but not entirely. I feel there is a legitimate reason to have a notification window prevent the device back button from working. FOr example, my app might alert the user, “Hey stupid, pay up or your account is deleted tomorrow!”. I’m sure you’re like me and probably everybody else on the planet, you’ve hit the back button on a notification in “real” apps out of instinct without ever reading them. Very much like clicking “Accept” without reading the EULA for a program. But some notifications should be purposfully interacted with, such as my example. The user should not be able to click outside the notification box to close it, and should not be able to click the device back button to close it… instead, the user should b required to click “OKAY” or whatever the notification button is.

But, even if we disagree with expected behavior, I think there is one thing that seems natural: if I have a non-cancelable notification visible, hitting the device back button causing the app to close doesn’t make sense. If the notification is cancelable=false, and you hit the device back button, the app closes… that seems the exact opposite of cancelable, but on a larger scale… instead of “not canceling” the notification, it cancels the app.

@Michael-Redwine As an update, I discovered that this problem doesn’t manifest itself if I set cancelable:true. If I do that, the back button closes the dialog. If I don’t set that, it closes the app.

Expected behavior: device back button does nothing until user dismisses the alert by pressing “OK” (or whatever the button says).