Firefox 4 cannot find plugins whose path contains high-ascii

RESOLVED FIXED in mozilla5

Status

()

--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: rsherry, Assigned: benjamin)

Tracking

({regression})

unspecified
mozilla5
x86
Windows XP
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 Macaw+, status2.0 .1-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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

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

Comment 2

8 years ago
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.
(Reporter)

Comment 3

8 years ago
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

8 years ago
(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

8 years ago
Do we know how to reproduce this?  If yes, I may be able to help.
(Reporter)

Comment 6

8 years ago
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

8 years ago
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

8 years ago
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.
(Assignee)

Comment 9

8 years ago
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

8 years ago
(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)

Updated

8 years ago
Assignee: nobody → benjamin
(Assignee)

Comment 11

8 years ago
Created attachment 523022 [details] [diff] [review]
Use unicode paths consistently, rev. 1
Attachment #523022 - Flags: review?(joshmoz)

Comment 12

8 years ago
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)
(Assignee)

Comment 15

8 years ago
Created attachment 524545 [details] [diff] [review]
Simple version, don't muck about with pluginreg because that breaks tests, rev. 1
Attachment #524545 - Flags: review?(joshmoz)

Updated

8 years ago
Attachment #524545 - Flags: review?(joshmoz) → review+

Comment 16

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

Comment 17

8 years ago
(The simple version, that is).
(Assignee)

Updated

8 years ago
Status: NEW → RESOLVED
blocking2.0: --- → ?
Last Resolved: 8 years ago
Keywords: regression
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
(Assignee)

Updated

8 years ago
Attachment #524545 - Flags: approval2.0?
(Assignee)

Updated

8 years ago
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.