Does this error occur just after your call to confluence.saveMacro() in both cases? If you’re not sure, are you able to add a debugger; statement to your code to determine which of your calls is the last to be executed before the error occurs?
I believe the stack trace you provided is from the host frame and not your app iframe so it has nothing to do with your Handlebars setup or dependencies. It is a bug in the Confluence front end code because it incorrectly assumes a particular ADF attrs node has a child node parameters, but I need to gather a little bit more information to help reproduce this. Does this problem occur no matter where you insert your macro? Are you able to investigate a little further on your side.
Thanks for confirming that @HendrikSchneider. From my own testing, I suspected the change of bodyType from rich-text to plain-text would make a difference, but I’m not sure why. You may be able to avoid changing back to rich-text if your macro view could be generated from the macro parameters rather than rendering the macro body directly.
I get the exact same error with a rich-text macro, is there any solution to this issue rather than changing the bodyType? My macro must have rich-text bodyType since it’s an element with a predefined style that users should be able to write their content inside.
i just found a workaround. The User has to create 2 Macros, one with Rich-Text and without a body. I store the Macro ID of the rich-text macro as a context property on the page and with the help of the REST API i can get the rich-text body of the macro and process it with the other macro…
But i hope the issue will be fixed someday, as i do not want the user to use 2 macros all the time.
Thanks for the quick response but unfortunately this isn’t a possible solution for me.
The macro I’m working on is part of an app we are developing and I can’t ask my users to use 2 macros for this solution.
I hope there is another solution for this issue