This behavior is confirmed on a server running 8.05
I have a project where I have a series of screens that have breakpoint containers for their root container. The large version opens a popup to display active alarms. The small view does not. The large view loads its popup in the “onStartup” method and closes the popup in the “onShutdown” method.
I think the breakpoint container is not triggering the onShutdown method for the large view when the breakpoint is triggered and the onStartup might be getting triggered when I come back into large view which appears to cause a memory leak. I don’t think the popups are getting deallocated and new ones are being opened.
I’m not sure where I look to figure out if this is indeed leaving popups open and opening new ones. All I know is that I was doing this on several screens on the app and we had to reboot the server because it locked up. I disabled all of the scripts that are doing this and rebooted the server last Thursday and we have not had problems since.
I didn’t see a method for showing me a list of all opened popups but if there is one I am interested in that information.
There is an open ticket regarding Actions (Popup, Navigation) failing silently when invoked during View onShutdown Events. Script Actions do not seem to exhibit the same behavior. Are you using Popup Actions in your scenario? If so, as a short-term workaround you could move those Popup Events into a script-equivalent to get this working for you.
I’m doing this in my onStartup for the view:
system.perspective.openPopup(‘myPopupId’, ‘Popups/Alarm Display’, {‘Alarm Group’:‘BlowerFlare’,‘TagFolderPath’:’[default]TagPath’}, position = {‘left’:250,‘bottom’:20}, showCloseIcon = False, draggable = False)
I’m doing this in the onShutdown:
system.perspective.closePopup(‘myPopupId’)
I'm on a recent 8.0.7 nightly, so my results could conceivably not match yours, but it'll be quite some time before I can switch to an 8.0.5 build and test there. Here is what I found on 8.0.7 (nightly):
I have a View (with a configured url of "/repl2") which has the same code you have, surrounded by log statements which declare which event I am in and what I'm about to do.
From the Bottom to the top:
- I navigate to a Page ('/repl') which does not have any popup actions taken on it.
- I then navigate to the Page which DOES attempt to open a Popup during View onStartup (Success - Popup is opened on arrival).
- I then navigate to a third Page ("/index") which has no popup actions taken on it (Success - Popup is closed as I leave "/repl2").
- I then navigate to the Page which DOES attempt to open a Popup during View onStartup (Success - Popup is opened on arrival).
- I then navigate to the Page which DOES attempt to open a Popup during View onStartup, and where the View is ALREADY open (Success - the View onStartup Script is not invoked because the View is already in place).
- I navigate to a Page ('/repl') which does not have any popup actions taken on it (Success - Popup is closed as I leave "/repl2").
I then attempted the exact same pattern while my browser width was reduced to fall within the small breakpoint of my "repl2" View, and I manufactured the exact same results. As a result, I don't believe that the user's Breakpoint has anything to do with the View Events triggering. Also, it might be an instance of miscommunication, but switching between configured breakpoints should not trigger/invoke View events, as you're not starting or stopping a View - you're only changing the layout of the current View.
I would wrap the relevant script with logging to verify it is executing as expected.
This doesn't mean the Event or Action is the problem, and based on my results I believe they are not. This most likely points to the View your are putting INTO the Popup as being the issue.
Sorry, I didn’t include a key detail (oops).
I have a breakpoint screen where the large breakpoint is a subview and that subview has the popup script on it.
The small breakpoint is actually another embedded view to another embedded view which does not have any scripting on it.
I probably just need to add my close event to the other embedded view to fix the problem.
