1736805 - String.prototype.normalize("NFD") gives weird result for specific string

Status: RESOLVED FIXED

(Core :: JavaScript: Internationalization API, defect, P1)

Description

[João Nelas]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I can reproduce in multiple computers (all Mac) by entering In the console:

" ç ".normalize("NFD")

The specific number of characters is important, but not the specific one. I can change the space to another ascii char, or the ç to another non-ascii char.

Actual results:

it returns

"\ue5e5\ue5e5\ue5e5\ue5e5\ue5e5\ue5e5\ue5e5\ue5e5\ue5e5ç "

Expected results:

it should return basically the same string

" ç "

Comment 1

[João Nelas]

This happens to me in Developer Edition, not normal Firefox.

And it started happening after version 90 something. I had a less used Mac that was still on that older version and it didn't have the bug, until I updated FF.

Comment 2

[João Nelas]

I've noticed that the display of the description is collapsing the spaces.

The problematic string is:

"         ç                      ".normalize("NFD")

Comment 3

[André Bargull [:anba]]

This should be P1 and backported to Beta.

Comment 4

[André Bargull [:anba]]

Attachment: Bug 1736805: Register written normalised length. r=#platform-i18n-reviewers!

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b89503a4811
Register written normalised length. r=platform-i18n-reviewers,gregtatum

Comment 6

[André Bargull [:anba]]

Comment on attachment 9247603 [details]
Bug 1736805: Register written normalised length. r=#platform-i18n-reviewers!

Beta/Release Uplift Approval Request

• User impact if declined: Users can see \ue5e5 (or \ue4e4 in debug mode) in strings returned by String.prototype.normalize. Both are jemalloc poison patterns.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It only sets mozilla::Vector::mLength to the correct value.
• String changes made/needed:

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1731080

Comment 8

[Ryan VanderMeulen [:RyanVM]]

(In reply to André Bargull [:anba] from comment #3)

This should be P1 and backported to Beta.

We've already built the Fx94 RC build. Are you saying this needs to drive an RC respin (i.e. be a dot release level issue)? If so, can you please offer some more context about the impact of the bug as it's not clear to me at the moment.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9247603 [details]
Bug 1736805: Register written normalised length. r=#platform-i18n-reviewers!

94 is on release now.

Comment 10

[André Bargull [:anba]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)

We've already built the Fx94 RC build. Are you saying this needs to drive an RC respin (i.e. be a dot release level issue)? If so, can you please offer some more context about the impact of the bug as it's not clear to me at the moment.

Probably yes. We read jemalloc poisoned memory, which is kind of bad. I haven't been able to create a test case which reads anything else than memory set to either 0xe5 or 0x00, but I can't say with 100% confidence that it isn't possible to create a test case which reads freed memory which isn't poisoned.

Comment 11

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/6b89503a4811

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9247603 [details]
Bug 1736805: Register written normalised length. r=#platform-i18n-reviewers!

Approved for 94.0rc2.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/382e21f9f40a