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

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

Possibly regressed by bug 1622042?

Zibi, known issue? Could you handle this?

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.

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

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

This is on Jared. See comment 4.

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

Moving to P3 as this is not happening in the next release cycle.

I can no longer reproduce this issue with the latest RTL - ar Nightly (103.0a1->2022-06-21) on Windows 10 and MacOS 11.0.