Blockly rendering on first load of page

[Erin Carvalho]

Hi again!

I've noticed that on the first load of a page blocks that are rendered by default in the workspace seem to get cut off. If I reload the page, it seems to render properly shown by the two images below. Any suggestions to remedy this. The behavior also seems to occur if I clear my cache and do a hard refresh.

Thanks,

Erin

[Beka Westberg]

Hello,

That's definitely weird. Do all of those blocks have different block definitions? Or are they being mutated to have different text? If they are being mutated, they may not be getting properly re-rendered when the field value is set.

If you're using a custom renderer that could also be causing a problem. I know there is caching related to measuring the size of text, which makes sense with what you're saying about triggering a hard refresh. If you are using a custom renderer please reply and I can dig up the caching code for you =)

I hope that gives you some places to start! Best wishes,

--Beka

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/74c6e46e-11b8-45ac-aa43-0a2e9f3a5c69n%40googlegroups.com.

[Erin Carvalho]

Hi Beka,

They all have different block definitions. I am not using a custom renderer. Here is my Blockly injection code. 

Blockly.Themes.Custom = Blockly.Theme.defineTheme('custom', {

 'base': Blockly.Themes.Classic,

 'blockStyles': blockStyling.blockStyles,

 'categoryStyles': blockStyling.categoryStyles,

 'componentStyles': blockStyling.componentStyles,

 'fontStyle': blockStyling.fontStyle,

});

const defaultOptions = {

 renderer: 'thrasos',

 comments: true,

 maxInstances: {

  'set': 1,

  'go': 1,

  'mouse_click': 1

 },

 toolbox: {

  'kind': baseBlockLibrary.kind,

  'contents': categories,

  'maxInstances': 1

 },

theme: 'custom',

};

Then I use some CSS to change the font and such

.blocklyTreeLabel {

font-family: Poppins, sans-serif;

-webkit-font-smoothing: antialiased;

-moz-osx-font-smoothing: grayscale;

color: black;

font-weight: 500;

}

.blocklyTreeRow {

padding: 3px;

margin-bottom: 1em;

}

.blocklyTreeRow {

height: initial;

}

.swal2-title {

font-family: Poppins, sans-serif;

}

 

Thanks,

Erin

[feni...@google.com]

I think Beka is on the right track: the size of text is changing when the font is changed. One way to check if this is the problem is to make sure your CSS is fully loaded before the call to Blockly.inject.

Rachel

[Erin Carvalho]

It seems like the CSS is already loaded plus from my understanding, that CSS only changes some aspects of the toolbox and not the blocks themselves. The custom theme I define should be handling block style right?

[Erin Carvalho]

Hi Rachel,

Any other suggestions to resolve this. The CSS is already loaded. I am using a Vue JS environment and I think it is related to the theme as I am not using a custom renderer. You can view the issue at https://a2s.fablevision-dev.com after reloading the page the issue goes away but after the clearing the cache the problem persists.

Thanks,

Erin

[Abby Schmiedt]

Hello!

I am having some problems reproing the issue, it seems very inconsistent. Are you still seeing it every time you clear the cache? 

I don't have any great ideas here, but here is some more information about how we determine the size of the block in hopes that it will help: 

• We first use the theme to set a few fields on the constants object about fonts. Such as constants.FONT_FAMILY.
• The renderer gets the correct size of the field from field.size_. This is set in the updateSIze_ method on the field. 
• updateSize_ uses getFastTextWidthWithSizeString to determine the width of the text field. This is where the font family and font size are used to determine the size of the field.

It looks like we cache the width. You could try calling Blockly.utils.dom.stopTextWidthCache to see if that fixed the problem, but I'm not sure what side effects calling that has. I think your problem is going to be somewhere in the getFastTextWidthWithSizeString method so I would recommend poking around here to see if you can find any differences between what is being run after clearing the cache and when the cache is not cleared. 

Sorry I can't be of more help, but hopefully that will give you some place to start!

Cheers, 

Abby