Blockly: Labels With Different Font Size are Not Rendered Correctly

[BeksOmega]

Describe the bug

Labels can be passed a class. If this class gives the label a different font size, it renders outside the bounds of the block.

To Reproduce

Steps to reproduce the behavior:

1. Add the following block definitions to the test blocks file:

{
    "type": "example_text_class",
    "message0": "%1",
    "args0": [
      {
        "type": "field_label",
        "name": "NAME",
        "text": "default",
        "class": "custom-text-class"
      }
    ],
    "colour": 230,
  },
  {
    "type": "example_text_class_image",
    "message0": "%2 %1",
    "args0": [
      {
        "type": "field_image",
        "src": "https://www.gstatic.com/codesite/ph/images/star_on.gif",
        "width": 50,
        "height": 50,
        "alt": "*",
        "flipRtl": false
      },
      {
        "type": "field_label",
        "name": "NAME",
        "text": "default",
        "class": "custom-text-class"
      }
    ],
    "colour": 230,
  },

1. Add the following css to the playground:

.custom-text-class {
  fill: black;  /* for visibility*/
  font-size: 50px;
}

1. Load the playground.
2. Import the following XML.

<xml>
  <block type="example_text_class"/>
  <block type="example_text_class_image" y="50"/>
</xml>

1. Observe how the text is rendered oddly. Especially on the block with the image.

Expected behavior

I expect the top of the text to be aligned with the top of the block (as that seems to be the current official behavior). The block should encapsulate all of the text.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Version: 75

(I believe this is not browser specific)

Stack Traces

N/A

Additional context

I think the problem is probably caused by this line being a constant (since size_.height is constant).

The y attribute is also set by the abstract field class here, and then overriden by the above line.

I know all of the field sizing stuff is a little iffy atm, I just think this is an important test case.

[rachel-fenichel]

@samelhusseini since I know you're looking at labels.

[samelhusseini]

Yup

[samelhusseini]

Fixed.

[BeksOmega]

From my testing I think this still occures. This issue is for classes that are applied directly to the label field.

[samelhusseini]

Sorry I meant to close the other one :)