We also experience this issue when using ApplicadtionOnReady event and trying to set favicon. Same issue, all vanila javascript is moved into a framework, that is not avaialble when you need it.

I think OutSystems should better guide with all these breaking changes in the release notes and share how to handle/fix them.

Also, adding extra code just to ensure OutSystemsUI.js is loaded, to me, doesn't seem to be a productivity improvement of easily using OutSystems UI.

Hi @Daniël Kuhlmann 

That one was already answered here and we have a reference on the release notes about this change (that's why we increased the minor, not the patch). That particular method will be fixed on next release but if it's a blocker you can use the workaround provided on the post I mentioned

Also, @Peter Van Den Ochtend the OnInitialize would not be the best place to call such actions looking at DOM elements. The OnReady would be more appropriate according to the lifecycle of the page.
If you do this everything will work as expected.

Hi Gonçalo,

We’ve also tried it on the on-ready. That didn’t work.

The last approach was to put it in a block and put it on the page. But then the user will see flashing screens.
the purpose of putting it in the OnInitialize so it would route the user to a different screen without flashing screens of the redirect.

I didn’t knew before this how the IsPhone check was working.

If you have a different way of determine the device of the user, please let me know.

Reading this issue. I didn’t see the instructions to solve this. In the change log there was one line that was saying something regarding public actions. But it didn’t ring a bell that it couldn’t break this kind of functionality. 

For now we put back version 2.8.3 and wait until it’s fixed in the next version.

Thanks !

Hi Gonçalo, I know the case I mentioned is already discussed. My point is, that change could also have been implemented to take care of checking and loading the required OutSystems Js files. It is not an improvement if a change in OutSystemsUI cause many OutSystems companies to refactor their code.

I totally agree with Daniel. Better maintainable / nicer code is always good but if it breaks functionality without informing the users of breaking changes is a no go. 

Hi Furkan

That case is identified and can be solved by the workaround mentioned on the other post

Hi Furkan,

the script is refactored and there is a check in the flow that checks for the availability of Outsystems functions. If not. Make it required. But apparently that doesn’t work. :( so manual action is indeed needed to make it work.

We're working on a possible solution to reduce the manual work you mentioned.
We hope to have a good solution to deliver on the next release since we put this as one of my top priorities.
A change like this is really hard and is a framework with a limited team working on it and several assets that need to cover all possible use cases on all apps in the OutSystems ecosystems is really hard to make it 100% at the first try (you all write software so you know that's true). We just ask you to trust us, continue to provide feedback and together with the community we'll reach a much better place with a more stable product that can be prepared to scale. Thank you!