Closed Bug 1517410 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox :: General, defect, P2)

Product:
Firefox
Component:
General
Version:
66 Branch
Platform:
x86_64
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 67
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 --- fixed
firefox67 --- fixed

People

(Reporter: alice0775, Assigned: jaws)

References

Details

(Keywords: regression, Whiteboard: [qa-66b-p2])

Attachments

(3 files, 1 obsolete file)

screenshot
(deleted), image/png
Details
Ubuntu18.04
(deleted), image/png
Details
Bug 1517410 - Don't show the unknown multiprocess status string while the page is loading. r?Gijs
(deleted), text/x-phabricator-request
lizzard
: approval-mozilla-beta+
Details
Attached image screenshot (deleted) —
Str: about:support Actual results: Multiprocess Windows 1/1 Unknown status Expected Results: Multiprocess Windows 1/1 Enabled by default
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)
(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)
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)
Attached image Ubuntu18.04 (deleted) —
And I can also reproduce the issue on Ubuntu18.04.
Flags: needinfo?(alice0775)
OS: Windows 10 → All
Attachment #9034450 - Attachment description: image.png → Ubuntu18.04
(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)
(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.
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)

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.

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.

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

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

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

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

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.

Attachment

General

Creator:
Created:
Updated:
Size: