RTL input field alignment is off

[maribethb]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

See screenshot below. In RTL mode only fields are misaligned. I see this is true in the multi_playground going back to at least blockly-v9.2.1

Reproduction steps

Stack trace

No response

Screenshots

Browsers

No response

[maribethb]

bisect says #6702 is the culprit. still looking into why this would matter only on RTL

[maribethb]

This happens because we need to position the WidgetDiv (the HTMLTextInput) after the block is done rendering, which now happens on a delay due to the render queuing system.

So you can fix the issue by waiting until the render is done like so (in field_input):

  private onHtmlInputChange_(_e: Event) {
    this.setValue(this.getValueFromEditorText_(this.htmlInput_!.value));
    requestAnimationFrame(() => {setTimeout(() => {
      this.resizeEditor_();
    }, 0);
  });

What I don't know is why you actually need to wait, since resizeEditor is already called during the render code. So just adding this bit of code is definitely inefficient, because we're resizing the editor twice, once during the render and once again immediately afterward. But when it's called during the render cycle, it has the wrong data and I'm not yet sure why, needs more investigation.

Also, this isn't the first issue caused by the general problem of needing to do additional rendering work after a block is rendered. So we might want to design a more elegant solution to that instead of just throwing more setTimeout calls whenever one of these pops up.

[maribethb]

As for why the position values are different when doing it during render vs after, they are different all the way to the getBoundingClientRect call inside getScaledBbox

I am not sure if this is because the getBoundingClientRect call is cached from the previous frame, or because the values genuinely change afterwards due to other rendering of the block. I read that you can invalidate the cache by writing to the dom before reading to it (note this is generally advised against however), so I tried that but still had the same issue, so I am guessing the latter.

Anyway gonna hold off on this further until we decide what to do about the broader issue.