MultiInstanceLock handles character encodings incorrectly
Categories
(Toolkit :: Application Update, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: emk, Assigned: agashlin)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
GetLockFileName
converts Unicode strings to nsCString
using nsPrintfCString
:
https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/toolkit/xre/MultiInstanceLock.cpp#43
nsPrintfCString
uses the ANSI code page:
https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/mozglue/misc/Printf.cpp#1042,1052
Then OpenMultiInstanceLock
convert the string back to UTF-16 using NS_ConvertUTF8toUTF16
, which is wrong:
https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/toolkit/xre/MultiInstanceLock.cpp#65
If the ProgramData folder path contains a non-ASCII character, this code does not work (although it usually does not).
Comment 1•4 years ago
|
||
Thanks for the detailed report, :emk -- we'll try to address this quickly.
Assignee | ||
Comment 2•4 years ago
•
|
||
I'll get to this shortly, along with bug 1697955. Fortunately it's probably quite rare for a system to have a ProgramData like this, :emk can you think of how it might occur, or did you encounter this in a sweep of nsPrintfCString misuses?
Reporter | ||
Comment 3•4 years ago
|
||
I happened to find a bad code smell when I look at the patch of bug 1696772.
In general, CreateFileW(PromiseFlatString(NS_ConvertUTF8toUTF16(filePath
is a bad signal unless you are sure filePath
is encoded in UTF-8. (C++20 char8_t
, please!)
Assignee | ||
Comment 4•4 years ago
|
||
nsPrintfCString %S converts from UTF-16 to the ANSI code page, but we rely on the output string being UTF-8.
Comment 6•4 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Description
•