Hi,
It seems the tab container’s runWhileHidden property is ignored by the breakpoint container. Any views inside will reload on tab change. This happens without any resizing by the browser, simply a tab change causes the reload.
I have created a simple project to reproduce the issue, which shows the counter resetting on every tab change. My actual issue is with dashboards reloading, but this demonstrates the issue.
Project: TestRunWhileHidden_2021-05-18_1104.zip (12.1 KB)
Regards,
Deon
Hi Deon, I took a look at your view. This is tricky.
Technically, what’s happening is when the TabContainer switches tabs, the Breakpoint Container is receiving display: none (from TabContainer’s runWhileHidden). This causes the Breakpoint Container’s width to change to 0, which triggers a change in breakpoints, subsequently resetting the view.
This is a tricky one to solve… We could code it so the breakpoint container doesn’t change widths while runWhileHidden is true and the tab is inactive… but eventually the width may change(due to say the Tab Container’s dimensions changing), and it may not be clear to the end user why the view reset.
That makes sense.
Right now I have a dashboard with a lot of widgets that always reloads on tab change, causing slow switching.
Having it only reload on size changes would be preferable.
The counter resetting was only to demonstrate the issue.
Is this something you can solve in the near future? Else I might use the viewport dimensions of 8.1.6 and attempt my own breakpoint behaviour.
I’ll file a bug ticket for it, I can’t promise a release date for a fix, but I’ll see if I can get it moved along 
Hello just wanted to check on the status of this fix. We are on 8.1.7 and are seeing the same issue
Thanks!
I’m sorry to say development on the fix has not been started. We have been making a push for bug fixes/polish items recently, mostly performance and undo stack related tickets. This ticket will for sure not be in 8.1.8. I’ll make a reminder to myself to bring this ticket up in the next development planning. 8.1.9 would be the earliest possible release for a fix, but again I can’t promise a release.
Understandable. I appreciate the transparency, as well as the response 