Closed Bug 644585 Opened 9 years ago Closed 9 years ago

Firefox 4 cannot find plugins whose path contains high-ascii

Categories

(Core :: Plug-ins, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed

People

(Reporter: rsherry, Assigned: benjamin)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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.
Benjamin, Jim - can one of you take a look at this?
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.
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.
(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.
Do we know how to reproduce this?  If yes, I may be able to help.
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.
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.
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.
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.
(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.
Assignee: nobody → benjamin
Attachment #523022 - Flags: review?(joshmoz)
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.
Attachment #523022 - Flags: review?(joshmoz) → review+
(er s/linux/32-bit linux/, in comment 13)
Attachment #524545 - Flags: review?(joshmoz) → review+
(The simple version, that is).
Status: NEW → RESOLVED
blocking2.0: --- → ?
Closed: 9 years ago
Keywords: regression
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
Attachment #524545 - Flags: approval2.0?
Attachment #523022 - Attachment is obsolete: true
blocking2.0: ? → Macaw+
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
Attachment #524545 - Flags: approval2.0? → approval2.0+
You need to log in before you can comment on or make changes to this bug.