Clicking on the link opens the popup widget as expected.
The problem appears when I try to close the popup by clicking on the back button in the popup navbar or by my own button (action: popup; popupClose: true) it closes the popup, closes the expoanded card and āclosesā the page. After a second the page is reloaded and re-appears.
This does not seem to be an expected behaviour allthough I see that a popup on top of an expanded card might lead to problems but I think that a popup opened in modal style should not interfere with whatever is underneath.
I suspect there are a couple of different issues going on here. One related to mixing the two popup options in the widgets. The f7 popup properties (e.g., popupClose) arenāt really meant to mix with the oh modal action. And the other based on the way f7 handles all these different types of elements that appear on top of page.
When you use the oh modal action to open a popup, oh adds that change to the pageās navigation stack. This is why the modal popup has a Back button (instead of a Close button). Creating your own popup via the f7-popup widget and opening it via popupOpen does not do this.
So, it seems that when you close your popup, that click event registers for the card as clicking outside the card and as a result triggers the card to close. This causes the popup to close automatically because the expanded card overlay and the popup overlay are getting the same close signal (Iām guessing here and canāt currently test it, but itās consistent with how I understand the f7 library to handle these things). Once those are both closed, the Back buttonās step backwards through the navigation stack still triggers, but instead of closing a popup (because itās gone), it sends a back event to the page itself.
Thereās a clear solution to the one half of the problem then. Build the popup yourself. You can easily use the f7-popup component and use the standard popupOpen and popupClose functions on it and add your other widget as the only child of that popup component (you wonāt get the navbar, but thatās part of the issue youāre trying to avoid).
The other issue you might not be able to avoid. This just strikes me as a collision of the overlay system within f7 library. Itās possible that thereās a way around this (you could try setting closeByBackdropClick to false on the card and see if that fixes it), but honestly, if it were me, that sounds like it will be more work than reworking the basic design. Maybe the things you have in the popup could be an accordion list instead, or something like that.
I did this before I had to change to a popup. The f7-list you see above recently had 700 entries. This resulted in creation of 700 hidden f7-popups, which causes the expanded card to load for 1 minute.
Thatās why I moved away from f7-popup to a separate popup opened by a click action.
Your explanation makes totally sense to me and I try to work from there to find a workaround.
You can get around this problem. The popup does not have to be a child of the list item. You can make it a child of the widgetās root component:
component: f7-block
component: f7-list
...rest of widget
component: f7-popup
This means there will only ever be the one popup. Then to make sure it can respond to all your 700 items, the link for each item should use both popupOpen and the variable action; they will both trigger when you click the link. Set whatever variable (or variable object) you need and just use the variable in the popup.