Malformed top bar

[rickmcgeer]

This happened again, on dataserver, and I captured a number of screen elements. Unfortunately, Google won't let me download the iframe HTML (or I don't know how to do it), so I settled for grabbing a bunch of screenshots and annotating them. I hope this helps:

1. The image showing the malformed top bar, with cross-references to the HTML elements:

2. Elements in the console, with the HTML for the Top Bar and the rectangle inside the bar annotated

3. Elements in the console, with the identifiable elements annotated

4. A mystery item that I can't identify that Elements selects, seen on the screen

[merryman]

Thank you for this analysis, this has cleared up a lot of things. There is good and bad news here. The good news is, that we now have a pretty clear picture of what is going wrong: If you look closely, you can see the the rendered css properties of the label morphs in the top bar are having: width: 0px; height: 0px which is obviously bogus. I am 100% sure however that this is in sync with the morphic properties of these labels themselves. So the error here is that the textBounds of the labels have been determined to be a rectangle with 0 width and height which in turn dictates the height and width of the labels themselves. (This is how labels work). Now this is another chapter in the never ending saga of trouble we get by rendering stuff via virtual dom. Since we dispatch the rendering of labels to a vdom, we have to wait after the render pass and also make sure that the fonts are all loaded. It seems like there is a chance were due to some timing issues, the morphic label logic never gets to finalize the text bounds and leaves them at the initial value wich is 0. I am pretty sure these kinds of bugs would be gone after a comprehensive refactoring of the morphic renderer as outlined here: https://github.com/LivelyKernel/lively.next/issues/213 The bad news is that this would take me 1-2 months full time, which as of now would mean I have to retract my participation from the dashboard product. We can discuss this in the next meeting.

[merryman]

One thing we can try is to load font awesome as part of the index.html of the frozen studio. That way we could make sure that the icon font is already up and running by the time the deserialization is happening. In that way we would evade the race condition that happens on load. We can try that and check if the issue persists.

[rickmcgeer]

Another thing I notice is that this always happens with small morphs, typically on the order of < 50 pixels. If we set a minimum size in the Virtual Dom, would that help matters?

[merryman]

That would mainly result in us not being able to render things smaller than 50 pixels. This would be no solution at all but just render morphic unusable.

[rickmcgeer]

Transfer to Jira