I suspect the issue is that you have set the z-index of a couple of the elements. It’s almost certainly showing, it’s just behind the overview page background (which has a z-index of 1 so you’re z-index of 0 is getting shunted all the way to back).
You usually shouldn’t need to worry about z-index (but that’s not a hard and fast rule), so I recommend trying to figure out what it is about the structure of the widget that seems to require this and restructure the entire thing so that you don’t need an absolute z-index and can just let the system handle it.
Open the browser console and watch the output there when you click on the cell. Make sure it doesn’t report any errors. If nothing shows up there then you really have narrowed it down to just a location of the rendered object issue and on a mobile screen like that there’s not too many places to hide other than “under other things”.
You have also given your popup a fairly unique class (test1234-pop), so when you think it should be open and you don’t see it, then search for the class name. You should just be able to click anywhere in the elements widow and press ctrl + f to bring up an input that will search the whole page structure. That will let you know that the element is actaully on the page, you just can’t see it and you can then see if changing some of the position or z-index parameters brings it back to visible.
I cannot replicate the issue with the test widget you’ve provided. It works just fine both on my test page and on my overview page. I’m on a 4.1 snapshot that’s a few weeks old (#3576), so between 4.0.2 and your newest snapshot test. I’m testing it on chrome (although according to the angry “update” button at the top, I’m not on the very latest version of chrome); that appears to be the browser you are using as well in the video.
Do you see any errors appear in the browser console when you click on the button?
Ok, I think you’ve got something that warrants a github issue.
I was able to reproduce your error to some extent now. When I first tested your stripped down widget code, I actually saved it as a standalone widget and added that widget to the overview page. This works exactly as expected. Just now, I added that widget to the overview page again and also added the same yaml directly to the overview page right next to it. This gives me two identical widgets side-by-side. The one that is the standalone widget still works as expected, but the one defined in-line on the page does not show any change in the variable status either on that widget or on another widget referencing that page variable. You are correct; there is something not working about variables defined on the overview page (which is odd, as that part of the overview page code does not appear to have changed in 3 years).
It has never been, and is still not, possible to define variables with default values in the widget editor. It has been possible to define variables on pages using defineVars nearly since the beginning because one of the original ideas behind variables was the ability to pass information between different widgets on the same page, and this gives the variables a page-wide context so all widgets can access them.
Indeed, it seems that whatever is impacting variable use on the overview page is effecting even the initializing of the variables using defineVars but only when displayed, the editing window does appear to work.
This is still the most mysterious part. It seems that eventually the overview page variable system does come online, but I cannot begin to image why this take 30 minutes. That make no sense at all to me.
I did not realize that defineVars should be available on the Overview page. This would go a long way to eliminate warnings such as:
07:59:32.346 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_Partition_In_Exit_Delay
07:59:32.346 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_Partition_Has_All_Zones_Closed
which result from the variable not having been initialized yet when the page is opened.
Hopefully some day my feature request will get picked up
So that is why I am getting this:?
2023-08-31 16:16:17.931 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn’t exist: undefined
If I open the page I get that warning.
Then I go to another page and if I open that page where I am getting the warning I don’t get the warning.
The widgets I have on that page all seem to work and I cannot see anything that I have that is not being referenced.
The warning I get doesn’t even say what the item is (that would be handy if it did).
It doesn’t bother me but it is something I have noticed.
When I get time I may look deeper into the issue.
I did modify a widget someone else had done and I cut bits out of it so there may be something I have missed.
Probably something I have done.
Your pages work fine because this is just a warning. It doesn’t interfere with the functioning of the page. But, it’s just as Mark said; it means that on that particular page you have a widget that attempts to connect to an item, but the expression that should result in the name of an existing item instead results in the name of an item which doesn’t exist (in this case the full expression result is undefined).
I went through a while back and fixed all the instances of that in my more used pages. It shaved about 250ms off of the loading time for the pages and got rid of the warnings and nothing else.