1794700 - Ensure button text shows up immediately in common dialog / wizard code

Status: RESOLVED DUPLICATE of bug 1819664

(Toolkit Graveyard :: Notifications and Alerts, defect)

Description

[:Gijs (he/him)]

In https://phabricator.services.mozilla.com/D159027#inline-875653 I became aware that data-l10n-sync="true" forces a sync translation pass for content that's initially in the DOM.

I wonder if this would help fix this bug that I've seen for a long time that bothers me, esp. on macOS (but I think it might be visible on other OSes):

1. open old-school profile manager by using -P flag on the commandline (or just making showing it the default)
2. click "create profile" button

ER:
the dialog/wizard animates smoothly

AR:
the dialog/wizard animates in, but the buttons are initially empty and then their text "clunks" into place

If you reopen the dialog a second time, it animates correctly.

This seems like a fluent issue that I'm hoping this attribute might help fix?

I've also seen this with other native macOS dialogs but I can't think of all that many off the top of my head, because we've converted a lot of them to be non-native, internal-to-Firefox subdialogs, which deliberately render in a visibility:hidden subframe and then get shown once all their content has loaded, in part to avoid bugs like this.

Comment 1

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #0)

I've also seen this with other native macOS dialogs but I can't think of all that many off the top of my head, because we've converted a lot of them to be non-native, internal-to-Firefox subdialogs, which deliberately render in a visibility:hidden subframe and then get shown once all their content has loaded, in part to avoid bugs like this.

To be clear, I wonder if this means we should also try doing this in commonDialog and friends, but I haven't found a good testcase that shows this issue off-hand.

Comment 2

[Eemeli Aro [:eemeli]]

data-l10n-sync="true" does not appear to help with the createProfile wizard.

If the button labels are directly set in the markup, then they are rendered before the animation.

Comment 3

[:Gijs (he/him)]

(In reply to Eemeli Aro [:eemeli] from comment #2)

data-l10n-sync="true" does not appear to help with the createProfile wizard.

If the button labels are directly set in the markup, then they are rendered before the animation.

Sorry, I'm not sure I follow - the string IDs are present in that bit of markup... Do you mean that the result of parsing that JS string is not inserted into the DOM in time?

Comment 4

[Eemeli Aro [:eemeli]]

Correct. I'm not sure exactly when, but the first translation pass appears to occur before the wizard's markup is in the DOM, so that its localized elements are only handled afterwards, even if the root element does have data-l10n-sync set.

Manually adding some label attribute values for the buttons shows those during the animation, and then replaced immediately after by the Fluent-localized labels.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:tspurway, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[:Gijs (he/him)]

I believe bug 1819664 fixed this.