Thanks, @JonnoKatahanas - a quick test in one eap instance and it looks likes it’s working. Thank you.
Thank you @JonnoKatahanas:
On our EAP instance we now see that the macro editor is using the original editor experience (which works fine) for adding text to the body of a plain-text body Connect macro.
It did require the browser cache to be disabled/refreshed to see it.
To be clear, we never saw any problems in production, only in EAP. @BobBergman
Is the plan to use the fallback to the original macro editor as a permanent fix or should we watch EAP for another try with the new macro editor?
Thanks!
hi @JonnoKatahanas we tried in Incognito in case this might be caching issue, but am still getting the old experience as far as I can tell. Can you help?
@EvangelosMantadakis can you please email me the instance you want this on and we will check for you. My email is jkatahanas@atlassian.com.
It also may be that the macros you’re testing are still using the old configuration.
many thanks @JonnoKatahanas, I sent the email with the instance !
I ran into what I think is another bug in EAP today:
For a rich-text body Connect macro: put a Table macro in the body. Renders fine in non-EAP. In EAP (fabric page) it renders in page edit mode but in page view mode it renders a “Edit to setup” thingy:
I have not yet had time to fully explore the EAP to try to find all the bugs that affect our Connect apps. From what I’ve found so far I am confident that there are enough problems with editing and rendering Connect macros in EAP that I’m going to miss some significant ones.
I suspect that Connect macros were not considered or tested during the development of the new macro editing (and rendering) experience. This is going to be risky for Connect app vendors, no matter what we do from here on out. Too many corner cases for us to find them before customers do, imo.
Dogfooding is when a framework provider uses their own framework to prove their framework.
I believe that it is important for Atlassian to build a suite of Connect apps and develop and test things like new macro editors with those in mind. In the short term, develop a suite of representative test Connect macros for use in projects like this.
Over the long term, replace the internally implemented macros with Connect or Forge or whatever frameworks vendors have available. When a new macro editor breaks every macro Atlassian has then that will be noticed in build number 1 and never make it to EAP. That is dogfooding.
Thanks.
This
I just talked to a colleague about a problem they thought they had found with the new macro editor in EAP. They could not save their changes.
It turns out they did not find a bug, they were just confused by the “X” that is used to save the changes made in the macro editor.
This reminded me that I was also initially confused by this detail of the UI and I had inadvertently trained myself to to use “X” as “Save” and to be very very careful while editing macros so I don’t get confused about what changes I made, requiring me to back out with a “Cancel” button that does not exist.
Imagine a macro with several text fields in it: a user edits a few of the text fields, realizes they are totally lost wants to abandon ship. How do they cancel? Ctrl-Z until they undo all of their typing so that when they click “X” it doesn’t save any changes? There are some complex macros out there… a user can’t rely on Ctrl-Z to get them back to the starting point… how do they know when they are there?
IMO, this really needs Save/Cancel, not “X”:
The X for save goes against all of my use of computers since I was in elementary school.
We do use custom configuration for full screen macro configuration modal which is crucial for our app experience as well as custom input parameters. We do hope that full screen option remain and would like to know if we will eventually be able to use custom configuration for custom input parameters in the new experience as well?
I agree this aspect of the UI needs further work. I have a dynamic content macro and you can see the impact of changes made to parameters. From that perspective, the X as a close not a save should be obvious because the changes have taken effect. But as has been pointed out, how do you then reverse a change, except by cancelling the whole page? Also, if the change takes place beneath the screen fold, you may not notice
I have a dynamic content macro and when the new side panel is open it shrinks the width of embedded macro body live preview, which impacts the live preview because it has a responsive & adaptive layout.
Another issue I’ve noticed with the side panel configuration dialog is that sometimes the live preview doesn’t reload after a series of parameter changes. You just get a blank box like this:
It’s a bit hard to tell if this happens in the old UI, because you need to save the changes to the parameters for it to take effect and my macro doesn’t fit fully into the preview anyway. I’m not seeing any errors in the console.
We opened DEVHELP-5738 to report a problem with the new macro editor breaking macro parameters of type “confluence-content” (essentially a Confluence page selector in the macro editor).
That ticket was recently closed by an automatic timer without being resolved.
This is a blocker for us, it breaks one of our popular Connect macros.
I’ll post an update to DEVHELP-5738 but I’m putting the details here too because this cannot be allowed to slip through the cracks. We need someone from Atlassian to reproduce the problem so that it can be fixed before the EAP changes are released to the public.
This is reproducible with our MultiExcerpt macro. It is a Connect macro.
A macro param that is a “confluence-content” param is not correctly pre-populated with the persisted value when the macro editor is used on a macro that was added to the page in a previously published version.
Before opening the macro editor the macro is fine. In page view mode the macro is working. In the page editor it is rendering a preview of the rendered macro. In the Storage Format, you can see that the macro parameter is set:
In page edit mode, open the macro editor and the “confluence-content” parameter is not populated in the editor’s dropdown for that parameter:
If you leave it that way the value is still set in the Storage Format and the macro works in page view mode but in the page editor it now says “Edit to setup” instead of showing the preview of the rendered macro. The macro no longer shows the preview in the page editor. Therefore, simply opening the macro editor breaks the preview of the macro in the page editor. The preview is now permanently broken until the user resets the value to its correct value (and then does not ever reopen the macro editor):
In the macro editor with the blank parameter, if you choose the correct/existing value in the editor, then that correct value saves and then the preview works fine in the page editor but it breaks the next time you reopen the macro editor. Also, how do you know which value to choose? The correct/existing value is only visible in the Storage Format for the page.
I broke several of the macros on my test site before I figured out this behavior of this bug. The behavior is complex and hard to understand so users make things worse while they try to figure out what is going on.
@JonnoKatahanas : heads up we are trying to get someone to address this macro editor bug before the EAP goes public.
Thanks.
UPDATE: I don’t have permissions to reopen DEVHELP-5738. Can someone from Atlassian please reopen it?
To make sure the plain-text body macro editing bug is not forgotten: the EAP macro editor is currently falling back to using the old/original macro editor for plain-text body macros because it was not possible to enter text into the macro body using the EAP editor.
We had opened DEVHELP-5737 for that and were told that the the rollback will stay until the engineering team can find a better solution to the pain-text macro improvements and that they would update us in CDAC.
This thread might be a good place for that update:
Should we expect the EAP macro editor’s first released version to use the fallback to the old editor for plain-text body macros or should we be prepared to test the new solution before this EAP goes public?
Thanks.
Big problem for our macros too! Any update on this? Thanks for reporting!
We opened DEVHELP-5738 to report a problem with the new macro editor breaking macro parameters of type “confluence-content” (essentially a Confluence page selector in the macro editor).
Thanks for raising it @TureHoefner. I just created an internal blocker ticket to address this issue before rollout.
UPDATE
In page edit mode, open the macro editor and the “confluence-content” parameter is not populated in the editor’s dropdown for that parameter:
This is a regression we also discovered recently and already fixed it. Currently, we are waiting for the build to reach production.
If you leave it that way the value is still set in the Storage Format and the macro works in page view mode but in the page editor it now says “Edit to setup” instead of showing the preview of the rendered macro. The macro no longer shows the preview in the page editor. Therefore, simply opening the macro editor breaks the preview of the macro in the page editor. The preview is now permanently broken until the user resets the value to its correct value (and then does not ever reopen the macro editor)
Even though it wasn’t showing the value because of regression but the value was available in the storage format like you mentioned. So it shouldn’t show the “Edit to Setup”. We will investigate this more.
Should we expect the EAP macro editor’s first released version to use the fallback to the old editor for plain-text body macros or should we be prepared to test the new solution before this EAP goes public?
Initial release will go out with the fallback. We will communicate before rolling out any changes to plain text macro.
Noting another new behaviour we have observed with the new ‘confluence-content’ parameter type in the new macro editor: It is no longer possible to save arbitrary text values.
On the existing (old) default macro editor, you can use a confluence-content field to search for confluence content, but you can opt to not select from the results and instead put any url there and save it. We rely on this behaviour in our Button macro, allowing users to link to content not necessarily from the current Confluence site.
In fact this is how the confluence-content parameter has behaved on both cloud and server going back many years.
The new macro editor changes break this expectation and would result in data loss for users of our macro, so if it’s intended we’ll have to come up with a different implementation.
We fixed the confleunce-content
problem that you reported and it’s in production now.