1634402 - Date information are shown in about:logins page for RTL builds only after the page is refreshed

Status: NEW

(Firefox :: about:logins, defect, P2)

Description

[Anca Soncutean [:Anca], Desktop Release QA]

Attachment: screenshot.png

Affected versions

• 77.0a1
• 76.0

Affected platforms

• Windows 10
• macOS 10.15
• Ubuntu 18.04

Steps to reproduce

1. Open a RTL Firefox build (eg. ar)
2. Save credentials for any website (eg. https://www.facebook.com/)
3. Open the about:logins page
4. Observe the تاريخ الإنشاء (Created) / آخر تعديل (Last modified) / آخر استخدام (Last used) fields

Expected result

• The date of the corresponding action is displayed for every section

Actual result

• “???” is shown instead of dates

Regression range

• I ran a regression manually with the following result:
  • https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3e5a7430c8d7d87bfeff471e62643185393a34c6&tochange=c644dd16e2ccf8bb78268202f60c767a569d9d77

Additional notes

• The dates are shown after the about:loggins page is refreshed once
• Reproducible on he locale (RTL build as well)
• Not reproducible on en-US, de, zh-CN

Comment 1

[Tim Spurway [:tspurway]]

m_kato, could you prioritize this one? Also do you think this should be tracked for a dot release?

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Possibly regressed by bug 1622042?

Comment 3

[Makoto Kato [:m_kato]]

Zibi, known issue? Could you handle this?

Comment 4

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

I looked into it, and found two-layer issue:

1. https://searchfox.org/mozilla-central/source/browser/components/aboutlogins/content/components/login-item.js#198-206

This code fallbacks are wrong. They use "" as a fallback, but since this is used as epoch it should be a number.

2. With (1) fixed, the values of this._timeCreated|this._timeUsed|this._timeChanged is falsy in ar but not in pl or en-US

I'm not sure what causes the difference, it may be a race condition maybe? But it seems like some timing bug since I don't believe this code should be called with falsy values.

It also explains why after reload it looks good (since the values are not falsy anymore).

I'm tentatively reassigning it to about:logins component because while the bug is visible depending on locale, it seems like the solution requires understanding why those variables are falsy.

I also couldn't reproduce it in pseudolocalization, so my first hypothesis is that since ar is incomplete, we load two locales, which takes a bit more time, and somehow in that scenario those variables are falsy.

If we end up finding out that some Intl code is causing them to be falsy, it may be moved back to Core::Internationalization.

NI on Jared, since he wrong those lines.

Comment 5

[Pascal Chevrel:pascalc]

What's the status for this bug wrt our upcoming releases? Thanks

Comment 6

[Tim Spurway [:tspurway]]

S1 or S2 bugs need an assignee - could you find someone for this bug?

Comment 7

[Matthew N. [:MattN]]

This is on Jared. See comment 4.

Comment 8

[(Away until May 24) Jared Wein [:jaws] (please needinfo? me)]

I question putting this at S1 or S2. The metadata is not critical functionality and a workaround does exist.