1517410 - Multiprocess Windows indicates 1/1 Unknown status in about:support

Status: RESOLVED FIXED

(Firefox :: General, defect, P2)

Description

[Alice0775 White]

Attachment: screenshot

Str:
about:support

Actual results:
Multiprocess Windows 	1/1 Unknown status

Expected Results:
Multiprocess Windows 	1/1 Enabled by default

Comment 1

[:Gijs (he/him)]

WFM on mac. Are you seeing this in a clean profile?

Also, what's the deal with the bizarre path separators for your profile path, were those always like that? Is that expected on your system? (I doubt it?)

Comment 2

[Alice0775 White]

(In reply to :Gijs (he/him) from comment #1)
> WFM on mac. Are you seeing this in a clean profile?

Yes, I always report a bug and confirm the bug using new profile.
And it reproduce with new profile.

> 
> Also, what's the deal with the bizarre path separators for your profile
> path, were those always like that? Is that expected on your system? (I doubt
> it?)


It depends with system font of Windows 10 Home Japanese edition. And This is normal.

Comment 3

[:Gijs (he/him)]

Jared, I won't have access to a Windows machine until Thursday, so can you take a look as I can't repro on mac? Sorry!

(In reply to Alice0775 White from comment #2)
> (In reply to :Gijs (he/him) from comment #1)
> > WFM on mac. Are you seeing this in a clean profile?
> 
> Yes, I always report a bug and confirm the bug using new profile.
> And it reproduce with new profile.

OK, thanks. Are there any errors in the browser console when you load about:support that might give a clue to what's wrong?

Can you right-click the text "Unknown status", and click 'Inspect Element' - and then in the inspector that comes up, open the context menu on the highlighted item, select the 'copy' submenu, and then 'Outer HTML', and paste the result here? I get:

<span xmlns="http://www.w3.org/1999/xhtml" id="multiprocess-box-status" data-l10n-id="multi-process-status-1">Enabled by default</span>

> > Also, what's the deal with the bizarre path separators for your profile
> > path, were those always like that? Is that expected on your system? (I doubt
> > it?)
> 
> 
> It depends with system font of Windows 10 Home Japanese edition. And This is
> normal.

It makes me sad that this is normal, but at least we've not also caused that bug here...

Comment 4

[Alice0775 White]

Attachment: Ubuntu18.04

And I can also reproduce the issue on Ubuntu18.04.

Comment 5

[Alice0775 White]

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

> OK, thanks. Are there any errors in the browser console when you load
> about:support that might give a clue to what's wrong?
> 

No error in Browser Console.


> Can you right-click the text "Unknown status", and click 'Inspect Element' -
> and then in the inspector that comes up, open the context menu on the
> highlighted item, select the 'copy' submenu, and then 'Outer HTML', and
> paste the result here? I get:
> 
> <span xmlns="http://www.w3.org/1999/xhtml" id="multiprocess-box-status"
> data-l10n-id="multi-process-status-1">Enabled by default</span>
> 


<span xmlns="http://www.w3.org/1999/xhtml" id="multiprocess-box-status" data-l10n-id="multi-process-status-1">Unknown status</span>

Comment 6

[:Gijs (he/him)]

(In reply to Alice0775 White from comment #5)
> <span xmlns="http://www.w3.org/1999/xhtml" id="multiprocess-box-status"
> data-l10n-id="multi-process-status-1">Unknown status</span>

I'm pretty lost as to how this can happen. The string definition for multi-process-status-1 is here:

https://searchfox.org/mozilla-central/source/toolkit/locales/en-US/toolkit/about/aboutSupport.ftl#266

The box starts out with status-unknown in the markup:

https://searchfox.org/mozilla-central/source/toolkit/content/aboutSupport.xhtml#171

but we set the status here:

https://searchfox.org/mozilla-central/source/toolkit/content/aboutSupport.js#82

So this feels like a fluent bug to me... it should either have already translated the contents of the span and then update them, or it should not have translated them yet and then it should be using the new string ID.

Comment 7

[:Gijs (he/him)]

And if it is a fluent bug, it's more likely to be a race condition, or perhaps reproduce more easily if your OS language and Firefox's language are not the same. I was just able to see the bug once, for the first time, but then I refreshed like 100 times and things always worked... Reproducing seems easier the first time after startup, but even that is intermittent/rare for me.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

I can reproduce this. It is almost certainly a race condition. It is easy for me to reproduce when I put Ubuntu in Japanese and keep Firefox in English. I have the same results as comment 7, easy to reproduce right after startup, harder afterwards.

Zibi, do you want to take this?

Comment 9

[Gary [:streetwolf52]]

I also get some screen corruption the first time i run about:support. Running Windows 10.

Comment 10

[:Gijs (he/him)]

(In reply to Gary [:streetwolf] from comment #9)

I also get some screen corruption the first time i run about:support. Running Windows 10.

This is a flash of unlocalized content. Please file a separate bug for this, in Core :: Localization.

Comment 11

[Gary [:streetwolf52]]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1518252

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

This is happening because DocumentL10n::TriggerInitialDocumentTranslation() calls mDOMLocalization->ConnectRoot(), which sets up a MutationObserver, then immediately afterwards calls mDOMLocalization->TranslateRoots().

TranslateRoots is an async method, so there is a potential that the script on the page will set localization IDs and attributes while the initial TranslateRoots is still working.

One way to solve this would be to wait for TranslateRoots to finish before setting up the MutationObserver, though that could introduce other bugs where l10n IDs and attributes are not updated correctly.

The way that I believe this bug can be fixed is to abort translation of fragments in TranslateRoots if the root was updated via the mutationObserver.

I'll try to put together a patch.

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1517410 - Delay applying localization from mutations until after l10n-ready.

By delaying the mutation updates until after l10n-ready this bug is fixed, but there is a significant delay before many of the strings are updated (about 3s).

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #13)

By delaying the mutation updates until after l10n-ready this bug is fixed,
but there is a significant delay before many of the strings are updated
(about 3s).

This delay is only noticeable if about:support is set as the homepage and during startup. Loading this page or about:preferences after startup doesn't show this delay.

Comment 16

[Jared Wein [:jaws] (please needinfo? me)]

With the patch from bug 1518252 applied I can no longer reproduce this.

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

My guess is that its because we removed a forced microtask alignment between when the translation happens and when mutations are being observed.

Can someone test if this also works well when you use a langpack? If so, I believe we can close this bug.

Comment 18

[Jared Wein [:jaws] (please needinfo? me)]

I can still reproduce this on English with about:support as my home page but only with debug builds.

Comment 19

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1517410 - Don't show the unknown multiprocess status string while the page is loading. r?Gijs

Comment 20

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jaws] (Regression Engineering Owner for 65) (please needinfo? me) from comment #18)

I can still reproduce this on English with about:support as my home page but only with debug builds.

I now can't reproduce it anymore, maybe when I saw it yesterday it was not actually showing "1/1 Unknown Status" but just "Unknown Status" while loading.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4c5d9edb2d6d
Don't show the unknown multiprocess status string while the page is loading. r=Gijs

Comment 22

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/4c5d9edb2d6d

Comment 23

[Julien Cristau [:jcristau]]

Do we want to uplift this, or is bug 1518252 in 66 enough?

Comment 24

[:Gijs (he/him)]

Comment on attachment 9039837 [details]
Bug 1517410 - Don't show the unknown multiprocess status string while the page is loading. r?Gijs

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1507595

User impact if declined

Confusing state of multiprocess support in about:support

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

No

Needs manual test from QE?

No

If yes, steps to reproduce

List of other uplifts needed

n/a

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

Just removes a single translation attribute from the markup so we'll only set it at runtime

String changes made/needed

n/a

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9039837 [details]
Bug 1517410 - Don't show the unknown multiprocess status string while the page is loading. r?Gijs

Fix for l10n regression in about:support; OK to uplift for beta 5.

Comment 26

[Mohammad Maruf Rahman]

I have reproduced this bug with Nightly 66.0a1 (2019-01-02) on Windows 10, 64 Bit and the fix of the bug is verified with latest Nightly 67.0a1!

Build ID : 20190202213603
User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Comment 27

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e2f693bac4d4