text input: retry the font family resolve when the font asset lands

[Cyannide]

Objective

An EditableText field whose TextFont names a FontSource::Handle can end up
rendering in parley's default family for the rest of its life.

update_editable_text_styles pushes the resolved family only when
text_font.is_changed():

if text_font.is_changed()
    && let Ok(resolved_family) = text_font.font.resolve_font_family(fonts.as_ref())

On the frame a field spawns, its handle is usually still loading, so
resolve_font_family fails. TextFont is not is_changed() again after that
frame, so nothing ever retries: the font asset finishes loading, gets registered
into the FontContext, and the editor is never told to use it.

The field is left with whatever family parley defaults to, while an equivalent
non-editable Text node picks the font up correctly.

Solution

Also attempt the resolve when Assets<Font> changes, which is exactly when a
late handle becomes resolvable. One extra insert(FontFamily) per editable
field per font-asset change; it is skipped entirely once the resolve succeeds
and no further font assets arrive.

A narrower alternative would be to read AssetEvent<Font> and match the
Added/Modified ids against each field's handle. That is more code for a
system that already runs every frame and whose body is a handful of style
inserts, so this takes the simpler condition.

Testing

Found while chasing a related bug in a fork of 0.19, where the same skip also
swallowed LineHeight and TextLayout syncing (that code used continue
rather than a let-chain, so an unresolved font skipped the rest of the loop
body; main's let-chain refactor already fixed that half). With the retry, a
field whose font handle resolves a frame or two after spawn renders in the
requested family; without it, it never does.

[alice-i-cecile]

Can you make this comment briefer? I have a hard time piecing together what it means in the current form. Logic seems fine though :)

[Cyannide]

Can you make this comment briefer? I have a hard time piecing together what it means in the current form. Logic seems fine though :)

I tried, but I think I just made it longer 🤣

[alice-i-cecile]

Clearer still!

[ickshonpe]

I thought about adding this fonts changed check in #25450, but there is already a mechanism to set TextFonts changed when fonts are loaded, so it seemed like it would be okay without it. Maybe there is some weakness in the font loading detection logic, it is quite convoluted and confounded by system ordering etc.

It isn't ideal to update all EditableText's on any font asset changes, but it seems fine for now as a defensive measure. It's not like fonts assets are updated constantly, and apps don't tend to have more than a handful of active input fields at once anyway.

[ickshonpe]

This test passes on main:

    #[test]
    fn test_update_editable_text_styles_reresolves_family_once_font_loads() {
        let mut app = App::new();
        app.init_resource::<Assets<Font>>()
            .init_resource::<FontCx>()
            .init_resource::<RemSize>()
            .add_systems(
                Update,
                (
                    load_font_assets_into_font_collection,
                    update_editable_text_styles,
                )
                    .chain(),
            );

        let font_handle = app.world().resource::<Assets<Font>>().reserve_handle();
        let entity = app
            .world_mut()
            .spawn((
                EditableText::new("some text"),
                TextFont::from(font_handle.clone()),
                ComputedUiRenderTargetInfo::default(),
            ))
            .id();

        app.update();

        assert!(!app
            .world()
            .entity(entity)
            .get::<EditableText>()
            .unwrap()
            .editor
            .get_styles()
            .inner()
            .values()
            .any(|style| matches!(style, StyleProperty::FontFamily(_))));

        app.world_mut()
            .resource_mut::<Assets<Font>>()
            .insert(
                font_handle.id(),
                Font::from_bytes(
                    include_bytes!("../../../bevy_text/src/FiraMono-subset.ttf").to_vec(),
                ),
            )
            .unwrap();
        app.update();

        assert!(app
            .world()
            .entity(entity)
            .get::<EditableText>()
            .unwrap()
            .editor
            .get_styles()
            .inner()
            .values()
            .any(|style| matches!(
                    style,
                    StyleProperty::FontFamily(parley::FontFamily::Single(
                        parley::FontFamilyName::Named(name)
                    )) if name.as_ref() ==
            &app
                .world()
                .resource::<Assets<Font>>()
                .get(&font_handle)
                .unwrap()
                .alias
                )));
    }

So I'm not sure how it would fail to reresolve on loading, do you have a reproduction?

[Cyannide]

This test passes on main:

So I'm not sure how it would fail to reresolve on loading, do you have a reproduction?

It may not even be an issue anymore because of the let-chain fix...it was reproducible before the let-chain with continue in place, but now the line height and alignment are properly handled at spawn even when the font hasn't resolved yet.