[BUG - 5694] BREAKING BUG ViewParams 8.1.12 (For custom components?)

With the new update 8.1.12 I was looking forward to the changes:
1518: Popup View params reset when popup is dragged

But it seems they break a bunch of stuff!

I have a binding on the viewparams and it keeps reverting to the inital values even without moving the popup, just trying to change the valeus isnt working.

I put a onchange script to log the origin and it seems the first time it goes right getting an origin from binding, but right after i get origin browser which sets it back to initial value…

This is quite the breaking bug, now they are instantly resetting instead of only when moved

It worked before the update => Confirmed by downgrading again to 8.1.11

1 Like

Update it seems to be working with the base ignition components?
However the property that i binded too is from my custom model, it gets changed through a javascript, might this be the case? Does it think it being changed by javascript is the same as moving ? Altho that should been been fixed already, did you prevent changing by javascript? (which was the cause of the moving bug?)

It worked before the update => Confirmed by downgrading again to 8.1.11

I do not seem to be able to easily replicate it on a different view/project tho… weird
ill test some further after lunch.

Set it to 8.1.12 and it again was resetting because of a browser origin.

I see nothing related in the wrapper logs


Sorry to hear about this. We can’t help you unless you give us a little more insight into your setup. Describe the contents of the popup, the popup configuration, and how view parameters are configured. The only thing that was changed on our end was in the popup itself, with better tracking of outbound view parameter values. The fix didn’t have anything directly to do with our components. So, I’m curious why your custom component and model is the exception?

1 Like

I dont have acces to the pc atm but i’ll list what i remember now.

I dont know if its really related to my component. Im really not doing anything special or weird with those props. Just a PropertyTree.write(array of dicts). That i trigger when a row is clicked in my table .But i dont know what else could trigger a prop change with origin ‘browser’ as i do know the props from my component get changed through an origin “browser”

The viewparams are supplied by the system.perspective.openpopup()
the view paramas is set to input/output <=> and one of them has a binding to my property.
It seems to happen on bi-direction and one way. The binding is confired on the viewparam.
The viewparam also has some onchange script on it.

the logs dont show anythign so maybe ill try and check with a wireshark to see where this 'browser" input comes from. The problem is it is on a gateway that is being used. And i wasnt able to replicate it on my local machine (yet)

binding and onchange script on a view param may not be ideal, but it works in 8.1.11 and even when i make a copy of the view (apart from the data) it seems to be working. And the data rly shouldnt affect this, it get changed back by the browser so…

im not rly doing anything special in my module for this prop, just setting it to [] on startup so no rows are selected…

Nothing on my end should be able to change the viewParam with an origin on browser, so it gotta come from the component of igntion, If im understaning the origins’browser’ right.
The weirdest is that it doesnt seem to be replicatable in a different view :frowning: it definitly happend again when turning to 8.1.12

In the copy which is working fine i made im getting onchange events from:

on startup of popup:
Project (passed down viewparams[dataArray]) => Binding(props(null)) => Browser(??its setting it back to viewparams[dataArray]??)
after changing something:
Binding (props)

I cant test on the other project atm, but it seems in this one it also gets set back to the default by browser, but only on startup. Could something have happend that causes it to sometimes keep triggering?

I added some breakpoints on my component in run time and it does seem like it only triggers the browser script after my component does something. But how can it change the viewparam while its not connected to it…
Does the property binding refer to the script in my code instead of just the value?

Welh its not this, i changed it to not even include a tree.write here yet the browser still triggered something to return it to the viewparams…

@ynejati @PGriffith @cmallonee @Kevin.Herron

(sorry if i referred to some unrelated staff, you 4 just seem to be the most active xd)
I have made a copy of your radComponent of github (might be an older version) and made a tiny adjusment to the image, just added in a tree.write which triggers on ever render that returns the date. Nothing special.

Then i’ve made a view which opens a popup with the binding as i have setup.
Most of the time (not always it seems) it also triggers the browser revert at the start

Please take a look into this
ive proved an export of the 2 views and the adjusted module
RadComponents-unsigned.modl (113.3 KB)
testStorage_2021-11-23_0043.zip (5.8 KB)
In my other project it sometimes even triggers not on startup, but all the time. But its hard to replicate even with my own component… But it has to be related to this.

Thank you for the additional information. Give me a little time to wrap my head around the situation. I’ll get back to you soon.

1 Like

Wait, is your custom component also writing back the tree in the render method? That will result in an infinite loop.

No it’s not, my component only writes at the start and on some client click events.
I just made this example as simple as possible xd As it seems i can only replicate it if it triggers very fast i figured the render would be the way.
In my project it also happends on the click events (so every write?), but i dont seem to be able to replicate that even if i copy the view.
I also was hoping one of these triggeres in the infinite loop would also get set back but seems that wasnt the case. I have no idea why i cant replicate what happens on the click events, but it gotta be related to this happening at the start too somehow. Some new write back in the main code somewhere?

Yes I encountered this as well. Whenever I would open up a popup it would reset the page params on the original view. Wound up recoding both views to only use params on startup.

1 Like

Welcome, Mitchell_Dennis.

Will you please explain to me how you have your popup configured. I’m not sure what “original view” means. Are you saying that your popup View is writing back to a property of the Page on startup? By “reset” you mean writing the value of a persistent property? Is this happening occasionally or is it consistent and easily reproducible? Thanks.

Scratch that. I’m able to reproduce the issue. Doing some investigating. Will respond with what I find. Thanks.

1 Like

It’s an incoming view property update that arrives after the popup is closed, gets stored (a mechanism of async view loading), and then applied once the popup opens again, but seemingly out of order. If you don’t interrupt the property sync between the view and the gateway, i.e. not closing a popup abruptly mid sync, you shouldn’t encounter this issue. Also, if it’s the first time opening the popup, you also shouldn’t encounter this issue. Anyways, we already have a solution, currently awaiting review, that is meant to address this general behavior. I’m glad you brought this up. We should have a fix up soon. Thanks again.

1 Like

For me on one of my views it triggered on every tree.write(). but i wasnt able to reproduce it elsewhere. But i hope the fix on startup also fixes that one^^

Thanks for looking into it and finding a quick solution! Let me know if its in the nightly so i can test if it works

Hi, there will be something in the next nightly that should hopefully fix the issues you are seeing. At least, it does fix the initial write back from the browser, and we hope it fixes your other issue relating to clicking. Let us know. Thanks.

1 Like

Im busy with another project right now, but ill check when i can. Thank you !


Sorry ive had to get my appendicitis removed so i been on sick leave, ill also have to catch up on work when i get back so yeah…

Ouch! Understandable. Please, take your time. That was just meant to be a friendly reminder. Rest up.

1 Like

So i got the 8.1.15 nightly and im still seeing the initial write back.
Did i get the wrong version or has it been changed again?

Hm no it does seem the banana gif isnt writing back anymore,
but my own component is…

anyways the click issue doesnt seem to happen again, but it was already hard to replicate so idk if that says anything right now xd

I must say the initial loading of my component isnt the cleanest, So it probably is interupting a bunch of things in itself, but i dont think that should trigger a de-sync on the popup level xd