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

RESOLVED FIXED in Firefox 66

Status

()

defect
P2
minor
RESOLVED FIXED
4 months ago
2 months ago

People

(Reporter: alice0775, Assigned: jaws)

Tracking

({regression})

66 Branch
Firefox 67
x86_64
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 unaffected, firefox65 unaffected, firefox66 fixed, firefox67 fixed)

Details

(Whiteboard: [qa-66b-p2])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

4 months ago
Posted image screenshot
Str:
about:support

Actual results:
Multiprocess Windows 	1/1 Unknown status

Expected Results:
Multiprocess Windows 	1/1 Enabled by default

Comment 1

4 months ago
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?)
Flags: needinfo?(alice0775)
(Reporter)

Comment 2

4 months ago
(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.
Flags: needinfo?(alice0775)

Comment 3

4 months ago
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...
Flags: needinfo?(jaws)
Flags: needinfo?(alice0775)
(Reporter)

Comment 4

4 months ago
Posted image Ubuntu18.04
And I can also reproduce the issue on Ubuntu18.04.
Flags: needinfo?(alice0775)
(Reporter)

Updated

4 months ago
OS: Windows 10 → All
(Reporter)

Updated

4 months ago
Attachment #9034450 - Attachment description: image.png → Ubuntu18.04
(Reporter)

Comment 5

4 months ago
(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>
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Flags: needinfo?(jaws)

Comment 6

4 months ago
(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

4 months ago
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.
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?
Flags: needinfo?(gandalf)
Comment hidden (typo)
Comment hidden (typo)
Comment hidden (typo)

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.

Flags: needinfo?(gandalf)
Priority: -- → P2
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).

(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.

Duplicate of this bug: 1520977

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

Depends on: 1518252

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.

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

Attachment #9035101 - Attachment is obsolete: true

(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

3 months ago
Pushed by jwein@mozilla.com:
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

3 months ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

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

Comment 24

3 months ago

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

Attachment #9039837 - Flags: approval-mozilla-beta?

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.

Attachment #9039837 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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

QA Whiteboard: [bugday-20190130]
Whiteboard: [qa-66b-p2]
You need to log in before you can comment on or make changes to this bug.