First Instance of Canvas Components are Rendering Incorrectly

[RaymondWood]

Several of the Canvas Components in my Canvas App are rendering inconsistently.

A deeper dive has revealed:

• This only happens in the Published App. The same version in Preview mode works as intended.
• Only the very first instance of each component is affected. On subsequent screens they appear normally
• Not all components in the app are affected.
• Affected components are both Local and from a Library
• Affected components internal controls (icons, labels, containers) are rendering at what appears to be the default control size and not the maker specified size.

• Example, in the screen shots below, the like-dislike icon
  • the icon renders at 64px x 64px (reported css in browser dev tools)
  • for "component.yaml" icon.width=20px, icon.height=20px  (maker set size)
  • for "icon.xml" width=64px, height=64px  (control default size)
  • the surrounding container is also affected though I didn't look into it.

• Example, in the screen shots below, the hamburger menu container
  • the container renders at 500px x 200px (reported css in browser dev tools) the width is visually truncated by the parent container
  • for "component.yaml" container.width=48px, container.height=48px  (maker set size)
  • for "groupContainer.xml" width=500px, height=200px  (control default size)
  • flexible heights/widths are turned off
  • the child hamburger icon does not appear to be affected.

Workaround

I worked around this issue by placing non-visible copies of the affected components on the loading screen. Effectively creating new first instances that the user never sees. This seemed to work.

With the work around in place I have moved on from the issue but want to know:

• Has anyone else had this problem?
• What is the root cause?
• Is this a known bug or backlog item?

   

  Published App

  

  Edited App

  

   

[cchannon]

I have not seen this exact issue before, but I have seen similar "fixed by adding an invisible thing" solutions. The best theory I can offer is that the runtime has limitations--or dare I say bugs--when it comes to tying a component property all the way up its dependency hierarchy to source data, if that hierarchy is complex.

It is especially easy to see bad behavior like this when you use Formulas to determine component properties (trying to build out color themes in a complex Formula object is basically guaranteed to fail in my experience), but it also happens when you chain a property through multiple data elements (e.g. Property W comes from Collection X which is built from rows in Gallery Y which is populated from Datasource Z) and certain control types seem to be more susceptible to these failures than others, namely the Modern controls.

Adding invisible elements seems to work by forcing the runtime to recompute the data before your control property is determined, for example, in that Property --> Collection --> Gallery --> Datasource example, if the property doesn't render correctly, or doesn't reflect updates in the datasource, I might try adding an invisible Gallery that just includes Collection X. The presence of this Gallery (I think) forces the runtime to recompute that data before trying to recompute the Property.

[RaymondWood]

Thank you cchannon. How do I report this as a bug?

[RaymondWood]

To add to the subject above. A few days after this post another component (a dialog box) in the same app seemingly, spontaneously rendered incorrectly (large buttons) after altering a few lines of code and publishing. The altered code had nothing at all to do with the affected component. Craziness!

A similar issue was raised in 2019, where Published and Previewed apps behaved differently.

[Florian_Kleinz]

I am facing the same issue on a project since this week. Thought placing the components invisible on the screen is a weird workarround. Glad to see, that I am not the only one.

[RaymondWood]

Thanks Florian. I have had Microsoft looking at this for a couple of weeks now. No solution as yet.