624789 - Mac OS X plugin code does not support non-ASCII characters in plugin name/description

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Jonathan Kew [:jfkthame]]

If there are non-ASCII characters in the name or description of a plugin, these strings will be missing from the information displayed in about:addons.

This can be demonstrated by adding a non-ASCII character to the Description string of the Test Plug-in; when viewing the Plug-ins panel in about:addons, the Description will be entirely missing.

This happens because the function CFStringRefToUTF8Buffer at http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginsDirDarwin.cpp#125 assumes that the UTF8 string will contain no more codepoints than the number of (UTF16) characters in the original CFString. This holds *only* for ASCII characters; as soon as a non-ASCII character is present in the string, the buffer will be too small and CFStringGetCString will fail.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: patch 1 - allow for non-ASCII characters when reading plugin info strings

This patch allows the nsPluginsDirDarwin.cpp code to read non-ASCII strings successfully.

However, I notice that the string is not correctly displayed in about:addons, so it looks like there's an encoding issue at another level as well.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: patch, v2 - allow for non-ASCII characters when reading plugin info strings

The nsPluginsDirDarwin code now returns strings as UTF-8, so we should _not_ apply a further encoding conversion to the bytes in nsPluginTag::EnsureMembersAreUTF8().

Once that is disabled, the non-ASCII plugin info displays correctly in about:plugins.

BTW, I'm working on a test for this in bug 607121 (which is how I first discovered that the Mac code was failing on non-ASCII strings).

Comment 3

[Jonathan Kew [:jfkthame]]

Comment on attachment 502923 [details] [diff] [review]
patch, v2 - allow for non-ASCII characters when reading plugin info strings

Requesting approval-2.0; this is needed particularly for i18n reasons, otherwise plugin names or descriptions that happen to include any non-ASCII characters (even just an accented vowel, “curly quotes”, copyright or trademark signs, etc) will completely fail to show up on OS X.

This is also needed in order to be able to create a cross-platform test for bug 607121 (which showed that such characters do indeed get used sometimes, even without considering localization). The OS X failure is actually worse than the Windows failure in that bug, as it causes the string to be dropped completely, not just a single character rendering incorrectly.

Comment 4

[Jonathan Kew [:jfkthame]]

http://hg.mozilla.org/mozilla-central/rev/616a453859c6