Closed
Bug 1275474
Opened 8 years ago
Closed 7 years ago
nsIUnicodeNormalizer should use ICU library if turned on
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
firefox49 | --- | affected |
People
(Reporter: m_kato, Assigned: m_kato)
Details
Attachments
(2 obsolete files)
For reducing table...
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → m_kato
Assignee | ||
Comment 1•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=59d7f9522168811f1b8671ef30a6a379aab0abed
Assignee | ||
Comment 2•8 years ago
|
||
By bug 1261900, Compress and DecomposeNonRecursively are no logner used when ICU is turned on. So it shouldn't be used with ICU. Review commit: https://reviewboard.mozilla.org/r/55014/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/55014/
Attachment #8756257 -
Flags: review?(jfkthame)
Attachment #8756258 -
Flags: review?(jfkthame)
Assignee | ||
Comment 3•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/55016/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/55016/
Comment 4•8 years ago
|
||
IIRC, currently nsIUnicodeNormalizer implements an old version (3.2?) of Unicode, because of legacy IDN considerations. (I wanted to update it at one point -- there's probably still an open bug -- but the IDN dependency was a problem.) If we do this, updating the behavior of nsIUnicodeNormalizer when ICU is in use (which also means we're using ICU for IDN processing), then we'll be exposing different normalization behavior on Android vs other platforms..... Does that matter?
Comment 5•8 years ago
|
||
(In reply to Makoto Kato [:m_kato] from comment #2) > By bug 1261900, Compress and DecomposeNonRecursively are no logner used when > ICU is turned on. So it shouldn't be used with ICU. Bug-number typo: just FTR, the relevant bug there is 1161900.
Assignee | ||
Comment 6•8 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #4) > IIRC, currently nsIUnicodeNormalizer implements an old version (3.2?) of > Unicode, because of legacy IDN considerations. (I wanted to update it at one > point -- there's probably still an open bug -- but the IDN dependency was a > problem.) Ah OK. > If we do this, updating the behavior of nsIUnicodeNormalizer when ICU is in > use (which also means we're using ICU for IDN processing), then we'll be > exposing different normalization behavior on Android vs other platforms..... > Does that matter? I see. Before it, I should integrate ICU (Bug 1262102) at first. Until landing it, I should cancel this.
Assignee | ||
Updated•8 years ago
|
Attachment #8756257 -
Attachment is obsolete: true
Attachment #8756257 -
Flags: review?(jfkthame)
Assignee | ||
Updated•8 years ago
|
Attachment #8756258 -
Attachment is obsolete: true
Attachment #8756258 -
Flags: review?(jfkthame)
Assignee | ||
Comment 7•8 years ago
|
||
Also, this XPCOM uses some addons and plugin code (NPNVdocumentOrigin)...
Assignee | ||
Comment 8•7 years ago
|
||
I removed nsIUnicodeNormalizer
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•