644585 - Firefox 4 cannot find plugins whose path contains high-ascii

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Rudi Sherry]

We are updating Reader for Firefox for and using the registry to register our plug-in.  We want to use the same plug-in for Firefox, Chrome and AIR and have it only in one place: with the Reader installation.

By default, on Japanese, Chinese, Vietnamese, Hebrew and Arabic systems the path to the Reader installed folder includes local (high-asci) characters.  Thus the registry item pointing to nppdf32.dll also includes these characters since it's in the "AIR" folder.

When this happens, Firefox cannot find nppdf32.dll.  We have proven the same with QuickTime so it is definitely a Core issue not a Reader issue.

Comment 1

[Josh Aas]

Benjamin, Jim - can one of you take a look at this?

Comment 2

[Jim Mathies [:jimm]]

By high-ascii I assume you're talking about multibyte strings encoded in the local code page?

I think on older systems (like win98) for mb languages paths we're encoded using multibyte. But on XP and up everything should be in unicode. So I'm curious why your paths are using this encoding at all.

Comment 3

[Rudi Sherry]

I just meant characters with the high-bit set, regardless of encoding.

We'll look to see the specific encoding that gets put in.

To get this path, we type characters into the installer prompt using (presumably) the built-in IME.  There is quite a bit of code in between typing into the installer prompt and getting it into the registry and it's all Microsoft MSI code that does this so I don't know that we have a lot of control over the encoding...

But as it turns out, I was wrong about the default location: it's not using local (high-bit-set) characters, only lower ascii so by default it's OK.

Comment 4

[Jim Mathies [:jimm]]

(In reply to comment #3)
> I just meant characters with the high-bit set, regardless of encoding.
> 
> We'll look to see the specific encoding that gets put in.
> 
> To get this path, we type characters into the installer prompt using
> (presumably) the built-in IME.  There is quite a bit of code in between typing
> into the installer prompt and getting it into the registry and it's all
> Microsoft MSI code that does this so I don't know that we have a lot of control
> over the encoding...
> 
> But as it turns out, I was wrong about the default location: it's not using
> local (high-bit-set) characters, only lower ascii so by default it's OK.

Is that the case on say a german system where "Program Files" is the localized version? A multibyte string on windows would include extended ascii using the latin code page for something like that. (assuming your default location is in a default folder like PF. If it's not it may not be an issue.)

FWIW, on our end the code reads the registry path as unicode, and then works with unicode file api.

Comment 5

[(no longer active)]

Do we know how to reproduce this?  If yes, I may be able to help.

Comment 6

[Rudi Sherry]

This is what one of our developers said:

The same problem occurs if QuickTime is installed on the path containing non-ASCII characters
e.g. C:\Program Files\QuickTime <non-ASCII chars>\
 
Similarly to the PDF case, Firefox 4 shows blank for a QuickTime movie embedded in a HTML file, such as
http://trailers.apple.com/trailers/disney/piratesofthecaribbeanonstrangertides/
or a movie file directly drag & dropped into Firefox 4.

Comment 7

[Zbynek Michl]

I have the same problem with our plugin on Czech version of the Windows, where "Application Data" directory is localized as "Data aplikací".

Strange that I can see the plugin in "about:plugins" correctly, however it doesn't work.

Comment 8

[Jim Mathies [:jimm]]

I tested Quicktime using a latin e in the directory:

C:\Program Files (x86)\QuickTimĕ

Maybe QT is a bad example beacuase after the install there were no Mozilla Plugin reg entries added and neither the firefox plugin or the IE COM object ran properly.

Comment 9

[Benjamin Smedberg]

nsPluginTag.mFullPath:

+		nsACString_internal	{mData=0x09afb510 "C:\builds\test-unicode-×בג\nptest.dll" mLength=0x00000028 mFlags=0x00000005 }	nsACString_internal

And oddly-enough, it's a nsACString, which can't represent the path needed.

Comment 10

[Jim Mathies [:jimm]]

(In reply to comment #9)
> nsPluginTag.mFullPath:
> 
> +        nsACString_internal    {mData=0x09afb510
> "C:\builds\test-unicode-×בג\nptest.dll" mLength=0x00000028 mFlags=0x00000005
> }    nsACString_internal
> 
> And oddly-enough, it's a nsACString, which can't represent the path needed.

Pfft. I gave moz devs far too much credit.

Comment 11

[Benjamin Smedberg]

Attachment: Use unicode paths consistently, rev. 1

Comment 12

[Josh Aas]

Comment on attachment 523022 [details] [diff] [review]
Use unicode paths consistently, rev. 1

>-static const char *kPluginRegistryVersion = "0.14";
>-// The minimum registry version we know how to read
>-static const char *kMinimumRegistryVersion = "0.9";
>+// The current plugin registry version (and the only version we know how to read)
>+static const char *kPluginRegistryVersion = "0.16";

You only need to bump to 0.15 here.

Comment 13

[Daniel Holbert [:dholbert]]

This landed as http://hg.mozilla.org/mozilla-central/rev/e61659c0f0d4
but I backed it out as http://hg.mozilla.org/mozilla-central/rev/f9e753853aa7
because it caused orange in mochitest-1 (linux-only?), mochitest-oth (only linux has completed this test so far), & xpcshell (cross-platform orange)
Sample of each orange:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1301682079.1301682804.27518.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1301682076.1301683334.30209.gz
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1301682077.1301683084.28884.gz

Comment 14

[Daniel Holbert [:dholbert]]

(er s/linux/32-bit linux/, in comment 13)

Comment 15

[Benjamin Smedberg]

Attachment: Simple version, don't muck about with pluginreg because that breaks tests, rev. 1

Comment 16

[Daniel C]

This landed again as http://hg.mozilla.org/mozilla-central/rev/5c7b908fc1cc

Comment 17

[Daniel C]

(The simple version, that is).

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 524545 [details] [diff] [review]
Simple version, don't muck about with pluginreg because that breaks tests, rev. 1

Approved for the mozilla2.0 repository, a=dveditz for release-drivers

Comment 19

[(no longer active)]

http://hg.mozilla.org/releases/mozilla-2.0/rev/ceab2e4a52b5