Fix displaying font family in the editor

[miina]

Fixes #2828.
Fixes #2838.
Fixes #2839.

[swissspidy]

Thanks for providing such a quick fix!

Seems like quite a few selectors to remove. I'll try to dome some in-depth testing to see whether this causes any other issues.

Also, note to self that we could add some E2E test for the font family selection feature.

[miina]

It looked like .editor-styles-wrapper could replace all the other selectors.

I'll try to dome some in-depth testing to see whether this causes any other issues.

Thanks, tried to test it myself, too, always good to have someone else testing though.

Also, note to self that we could add some E2E test for the font family selection feature.

Yep, would be good to take the e2e tests into the dev process, I'm def happy to add some tests post-merge, also for the existing stuff. If I understand correctly then you already started within #2708.

[swissspidy]

Sounds great! Yeah started the basic e2e test setup in #2708 and now I‘d like to bring some structure and prioritization into this. See #2795

[swissspidy]

Now all the fonts in the editor are serif:

At least the text block's font family properly changes though, so there's that :)

[miina]

Hopefully works now. Tested the following:

• Correct font family in the editor.
• On refresh doesn't display Update button as active (font calculation is working OK)
• Font family changes display in the editor.

[swissspidy]

Looks better now.

Sorry for hijacking your PR, but I felt like this is a good opportunity to fix the block dimension and font size calculation. See 1187d73. Because right now font family changes are not being considered in these cases.

There's only one problem at the moment:

1. Create new text block with "Hello World"
2. Turn off fit-text
3. Change font family to Lucida Sans Typewriter
4. Text wraps on second line in the editor.
5. However, on the frontend it's all on one line.

Not sure why that is at the moment. I thought #2809 would fix that?

[swissspidy]

Not sure why that is at the moment.

Actually, when browsing the frontend in a 328x553 view, it looks the same. Just not in something like a 375x812 view.

[miina]

Actually, when browsing the frontend in a 328x553 view, it looks the same. Just not in something like a 375x812 view.

Then it should be OK, since the values are in % then we can't really control it beyond ensuring it looks the same with the same width/height.

[swissspidy]

Cool. If you can test my change too that would be excellent. Then we can merge and send it to QA.

[miina]

^ This check is actually already within maybeUpdateFontSize but I guess it doesn't harm to have it here + makes it more clear/readable, too.

[miina]

Seems to work well most of the time.

For some reason, sometimes with amp-fit-text it doesn't work properly, not sure why. Did the following:

• Added a text block with "Another test!" written in it.
• Started clicking through the fonts from top to bottom.
• In some cases, it didn't adjust the font size and the text went over the limits.

Note that this happened maybe once in clicking through the whole set of fonts so it's not something really easy to debug, we can probably look into this later if it should appear more, let's merge this.

[miina]

Also found this issue: #2839

Testing shows that happens on develop, too, so unrelated to the PR. Looking into it

[swissspidy]

For some reason, sometimes with amp-fit-text it doesn't work properly, not sure why.

I think this might be a race condition when the font stylesheet hasn't loaded yet, so the calculation does nothing because the font hasn't been applied.

[swissspidy]

Also found this issue: #2839

I think it's an easy fix. Let me push something really quick.

[swissspidy]

f2e7a5e also fixes a bug where a text block with turned off fit-text does not resize when writing a long text.

With this change, the story title block correctly changes font size or dimensions during typing of a very long title.

[miina]

LGTM!