Last Comment Bug 133282 - Scan for plugins in their installation folders
: Scan for plugins in their installation folders
Status: VERIFIED FIXED
[ADT1] [m5+] [hitlist]
: topembed+
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Windows XP
: P1 normal (vote)
: mozilla1.0
Assigned To: Peter Lubczynski
: shrirang khanzode
Mentors:
: 119056 140042 140766 142980 143013 (view as bug list)
Depends on:
Blocks: 121324
  Show dependency treegraph
 
Reported: 2002-03-25 08:56 PST by Peter Lubczynski
Modified: 2004-11-25 22:24 PST (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
possible patch? (9.13 KB, patch)
2002-03-25 09:01 PST, Peter Lubczynski
no flags Details | Diff | Splinter Review
patch v.2 (14.08 KB, patch)
2002-04-26 14:34 PDT, Peter Lubczynski
no flags Details | Diff | Splinter Review
patch v.3 (23.64 KB, patch)
2002-04-29 12:28 PDT, Peter Lubczynski
serhunt: review+
Details | Diff | Splinter Review
patch v.4 (28.50 KB, patch)
2002-04-30 13:04 PDT, Peter Lubczynski
serhunt: review+
waterson: superreview+
Details | Diff | Splinter Review
patch v.4 (whitespace stripped version) (24.81 KB, patch)
2002-04-30 15:54 PDT, Peter Lubczynski
asa: approval+
Details | Diff | Splinter Review
trunk patch (patch v.5) (28.65 KB, patch)
2002-04-30 20:26 PDT, Peter Lubczynski
peterlubczynski-bugs: review+
peterlubczynski-bugs: superreview+
Details | Diff | Splinter Review
patch v.5.1 (13.57 KB, patch)
2002-05-01 12:45 PDT, Peter Lubczynski
no flags Details | Diff | Splinter Review
patch v.5.2 (13.36 KB, patch)
2002-05-01 16:20 PDT, Peter Lubczynski
no flags Details | Diff | Splinter Review
patch v.5.3 (13.17 KB, patch)
2002-05-01 16:22 PDT, Peter Lubczynski
serhunt: review+
Details | Diff | Splinter Review
patch v.6 (branch patch) (29.55 KB, patch)
2002-05-01 17:07 PDT, Peter Lubczynski
serhunt: review+
Details | Diff | Splinter Review
patch 5.4 (trunk patch) (13.21 KB, patch)
2002-05-01 17:59 PDT, Peter Lubczynski
peterlubczynski-bugs: review+
attinasi: superreview+
Details | Diff | Splinter Review
patch 6.1 (branch patch) (29.59 KB, patch)
2002-05-01 18:01 PDT, Peter Lubczynski
no flags Details | Diff | Splinter Review
patch 6.1 (branch patch) (29.59 KB, patch)
2002-05-01 18:01 PDT, Peter Lubczynski
peterlubczynski-bugs: review+
attinasi: superreview+
asa: approval+
Details | Diff | Splinter Review

Description Peter Lubczynski 2002-03-25 08:56:51 PST
On Windows, we currently have the problem of forcing users to re-install plugins
and/or copy DLLs if the browser is installed AFTER the plugin. One possible idea
is to locate some of these installed popular plugins via the Windows registry
and scan for them in their installed location. We currently have this option for
Sun JRE 1.3.x and this bug is about extending that to other plugins.
Comment 1 Peter Lubczynski 2002-03-25 09:01:24 PST
Created attachment 75979 [details] [diff] [review]
possible patch?

Here's a patch that implements some new prefs:

pref("plugin.do_Acrobat_Plugin_Scan", true);
pref("plugin.do_Quicktime_Plugin_Scan", true);
pref("plugin.do_WMP_Plugin_Scan", true);
pref("plugin.do_4x_PluginScan", true);
pref("plugin.do_JRE_Plugin_Scan", true);  (exisiting)

With this patch, when these prefs are trued on, we'll go search for plugins
from where they are installed at run-time like we already can do for Java. The
4.x pref controls scanning all, none, or filtered like we do now.

Comments?
Comment 2 serge (gone) 2002-03-25 14:17:03 PST
There is a bug 76015 which addressed the same issue,
and definitely we have to implement something like this,
the patch looks workable to me.
For now I have only one concern - performance.
Is it possible to cache installed plugins info at mozilla installation time, and 
do not scan the OS registry after that at all? 
Comment 3 Denis Antrushin 2002-03-26 05:51:02 PST
nsPluginDirServiceProvider looks like a pure windoze stuff, so why not use
it only on windows? At least, why not put all those win-specific |if|s
undef single |#ifdef|? I mean  
if (some-crossplatform-stuff-if-any) {
}
#if defined (XP_WIN)
else if (win-only-stuff-1) {
} else if (win-only-stuff-2)
etc.
#endif

I think, the fewer |#ifdef|s, the better %-) 

OTOH, there is some plugin related stuff in xpcom/ds/XXXDirServiceProvider 
- can we use only nsPluginDirServiceProvider for plugin dir services (or, why we need plugin's own dir service provider?).

I'm not expert here, but I like bug 76015 approach more (put plugins in some
place instead of scanning registry).
Comment 4 Peter Lubczynski 2002-03-26 11:27:45 PST
Bug 76015 is a great place where we can track changes for the future, but it
does not help everyone who already has a plugin installed. Plus, asking plugin
vendors to change installers is not that trivial and takes a long time.

The patch in this bug will allow us to knock off some of the top plugins from
their exsiting installations. Therefore anyone, including embedding, can make
use of it without any installer foo. And there is some flexibility with the prefs.

Because of our plugin caching mechnism, I'm thinking this patch may not be that
much of a performance problem. Although cacheing in the appreg does need some
work in bug 109739 and the Windows registry may slow it down a bit, there aren't
that many extra files and checking time stamps isn't that expensive. I will
conduct some tests.
Comment 5 rubydoo123 2002-03-28 11:12:44 PST
moving to 1.0.1, this patch will help prevent those issues where the plug-in is 
already installed on the system, but the application doesn't recognize that 
fact.
Comment 6 Arun Ranganathan 2002-04-18 12:37:56 PDT
Firstly, this is a grotesquely undernominated bug.  This is an important
requirement for embedders such as the public AOL beta which pulls Mozilla, so
let's see some "+" "-)
Secondly, here's official scanning information from Adobe about the Acrobat
plugin, including details about i18n issues.  This was in response to my
question "does Adobe pre-emptively leave Netscape plugin DLLs on the Windows
desktop if there's no Netscape or Mozilla-based browser on the destkop?"

Yes it does.  For Acrobat, you can get the location from the following reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Adobe Acrobat\4.0\InstallPath
HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Adobe Acrobat\5.0\InstallPath
HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Adobe Acrobat\6.0\InstallPath
 
The default value under each of these keys is the path to the parent directory.
 It will look something like this:
C:\Program Files\Adobe\Acrobat 5.0\Acrobat
 
Append to it so you have this:
C:\Program Files\Adobe\Acrobat 5.0\Acrobat\Browser\nppdf32.dll
 
Note that there are a total of 15 files - nppdf32.dll is the binary with
USEnglish resources.  There are 14 additional files containing the resources for
other languages.  You can get all of these in the same folder by using a
wildcard, "nppdf32.*"
 
Hope this helps. 
Comment 7 Dave Barrowman 2002-04-18 14:11:29 PDT
Topembed+ per EDT triage.  Very important to embedding.
Comment 8 rubydoo123 2002-04-18 15:39:00 PDT
This particular issue has increased in importance, this will resolve the issues 
where the user is instructed to download a plug-in application, and after the 
install, they go back to the page where the plug-in instance is located and when 
they select it again, they are agian instructed to install the plug-in 
application. 
Comment 9 kmurray1115 2002-04-19 16:05:08 PDT
Stop ship for commercial release. 
Comment 10 Doug Turner (:dougt) 2002-04-24 16:31:52 PDT
Peter, 
NP parsing of the xpcom components directory should be disabled in the mozilla
build.  I suggest using some build flag magic which the commercial build (or any
build for that matter) can set to enable this hack.  

I don't want to promote nor support np-style plugins in the xpcom components
directory.  This leads to confusion as to where exactly plugins should be place.  
Comment 11 Arun Ranganathan 2002-04-24 16:38:01 PDT
The problems raised in Bugscape 14100 will be solved by "NP parsing" in Netscape
commercial browsers of the Components directory.  
Comment 12 selmer (gone) 2002-04-24 17:14:52 PDT
This bug seems to have morphed.  The installation folders referred to in the
summary are not the same as the xpcom components folder.  In particular, the
existing patch is nothing like an "NP parsing" solution.  Are we in the right
bug with this parsing stuff?
Comment 13 rubydoo123 2002-04-25 10:44:53 PDT
*** Bug 140042 has been marked as a duplicate of this bug. ***
Comment 14 Peter Lubczynski 2002-04-26 14:34:20 PDT
Created attachment 81215 [details] [diff] [review]
patch v.2

Alrighty, this patch has some new features (all controled by prefs):

* Scan for nppl3260.dll in a special, one-off hack, in the components folder
(do not do this if we've already found the Real mime-type elsewhere, like
perhaps with Real One in the plugins folder). This is on by default in all
builds, use a pref to turn off explicity.

* Scan the the latest JRE installed. With the JRE pref turned on, no longer
need to sync DLL's with the browser. We'll go and find the newest one, whatever
that may be, in its installation directory. Tested situation where 1.3.1_02
DLL's are in plugins folder and we STILL use 1.4 from it's installed location.
No DLL copying or regxpcom needed here, all these "features" are run-time
sweeps. This solves the "first-install" problem for Java.

* Scan for Quicktime, whatever version (only 1 can be installed at a time), in
its install directory. This should fix the missing QT DLL problem as well as
fix the QT control panel to actually correctly re-write the mime types in the
version table. This solves the "first-install" problem for Quicktime.

* Scan for Acrobat 5.0 in its installed location. It's hard-coded for 5.0, will
fix if time permits. This solves the "first-install" problem for Acrobat 5.

* Scan for Windows Media Player in its installed location. We'll pick whatever
version is there. I have not implemented a manditory version yet. This solves
the "first-install" problem for WMP.

* 4.x folder now has a pref. By default, with the pref missing, NOTHING HAS
CHANGED. You can now add this pref to control if all or none of the plugins for
the 4.x folder are scanning. This is here for QA and the Mozilla community to
test the feasibility of allowing all plugins in future expansion.

TODO:
* Do we want to limit the version of the plugin we sweep for? It's a little
more work and different for each plugin. How much time is left? Please advise
on what approach to take.

* Testing, testing, testing....It would be helpful it people could run with
this patch on all falvors fo Windows and all sorts of plugins. Version and OS
matter here. I'll turn on file sharing on my machine if QA would like to run my
debug build on different configurations.
Comment 15 dprice (gone) 2002-04-26 16:14:23 PDT
CCing myself.

when this lands will it find nppl3260.dll in a netscape 4.x plugins directory?
Comment 16 Peter Lubczynski 2002-04-26 19:17:07 PDT
No! We NEVER sweep for Real in the 4.x folder. 

We have a new problem now -- Real's installer is not finding Netscape because
we've changed some registry keys. For my full dissertation, see:
http://bugscape.netscape.com/show_bug.cgi?id=12512

Patch v.2 might be obsolete if Real isn't going to be dropping the DLL in the
components folder.
Comment 17 dprice (gone) 2002-04-27 05:06:56 PDT
We dicussed the fact that the fix for 12512 would be obsoleted when this lands.
 Once this gets in file a new bug on me and I'll take out it back out.  
Comment 18 rubydoo123 2002-04-29 10:33:11 PDT
*** Bug 140766 has been marked as a duplicate of this bug. ***
Comment 19 scottputterman 2002-04-29 12:13:49 PDT
Who can review and super review?
Comment 20 av (gone) 2002-04-29 12:25:32 PDT
I will review it today.
Comment 21 Peter Lubczynski 2002-04-29 12:28:23 PDT
Created attachment 81534 [details] [diff] [review]
patch v.3

New and improved patch:

 * By popular demand from embedding vendors, you can now specify a minimum
version for either JRE, WMP, Acrobat, or Quicktime for these "extra" scan prefs


 * New pref names:

+pref("plugin.scan.SunJRE", "1.3");
+pref("plugin.scan.Acrobat", "5.0");
+pref("plugin.scan.Quicktime", "5.0");
+pref("plugin.scan.WindowsMediaPlayer", "7.0");
+pref("plugin.do_4x_PluginScan", false);

For example, some versions of WMP 6.4 may crash. By specifying this pref, we
can limit to only 7.0 and above WMP:
pref("plugin.scan.WindowsMediaPlayer", "7.0");

Note: This "feature" is only for this extra pref scanning. If we find the
plugin DLL elsewhere, we'll use it.

Versioning is done differently for each plugin:
 * For QT and WMP, we actually look up the player's EXE and read the version
table
 * For Acrobat and JRE, we look in the registry at key values

Note: This patch removes the old plugin.do_JRE_Scan pref. Use this instead:
pref("plugin.scan.SunJRE", "1.3");

Please review/comment/test out.
Comment 22 av (gone) 2002-04-29 20:28:11 PDT
Comment on attachment 81534 [details] [diff] [review]
patch v.3

Looks like our plugin scanning architecture is approaching its limits.
Implementing new demands makes the code more and more ugly. Codewise it looks
fine to me, you can take it as r=av, but we should probably redesign it in the
future.

Before you do anything esle would you please fix tabs to be 2 space chars?

Is my understanding correct that we no longer do 4x sweep by default?
Comment 23 scottputterman 2002-04-30 12:02:45 PDT
Who should sr= this?
Comment 24 Peter Lubczynski 2002-04-30 13:04:45 PDT
Created attachment 81735 [details] [diff] [review]
patch v.4

Updated the patch from testing:

* Changed default indenting in nsPluginDirServiceProvider.cpp back to two
spaces
* Fixed problems finding Acrobat (can be in either 'Acrobat' or 'Reader' keys)
* Fixed leaking string in GetKeyValue
* other little nits
Comment 25 Peter Lubczynski 2002-04-30 13:10:24 PDT
Default 4.x folder sweeping has not changed. This patch now adds the option to
turn off filtering or completely shut it off.
Comment 26 av (gone) 2002-04-30 13:12:45 PDT
Comment on attachment 81735 [details] [diff] [review]
patch v.4

r=av
Comment 27 Peter Lubczynski 2002-04-30 15:54:32 PDT
Created attachment 81788 [details] [diff] [review]
patch v.4  (whitespace stripped version)
Comment 28 Chris Waterson 2002-04-30 16:21:57 PDT
Comment on attachment 81735 [details] [diff] [review]
patch v.4

sr=waterson.
Comment 29 scottputterman 2002-04-30 16:41:12 PDT
adding adt1.0.0+.  Please get drivers approval and then check into the branch as
soon as possible and add the fixed1.0.0 keyword.
Comment 30 Peter Lubczynski 2002-04-30 20:26:33 PDT
Created attachment 81819 [details] [diff] [review]
trunk patch (patch v.5)

This is the patch (v.5) that went into the trunk. It's been merged to the tip
(and with darin's NS_NewNativeLocalFile changes). As of right now, patch v.4
should apply to the 1.0 branch.
Comment 31 Peter Lubczynski 2002-04-30 20:31:45 PDT
Patch in trunk, marking FIXED and requesting Mozilla Driver's approval.
Comment 32 Asa Dotzler [:asa] 2002-04-30 20:43:00 PDT
Comment on attachment 81788 [details] [diff] [review]
patch v.4  (whitespace stripped version)

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Comment 33 Bernard Alleysson 2002-05-01 08:45:55 PDT
This doesn't work for me for Windows Media Player.
I have US English wmplayer.exe Build 8.0.0.4477.
I'm running Windows XP Pro.
I stepped through the code and here is what I found:

The way used to get file version is wrong. The file version is stored in a
VERSION resource which has 2 parts: one is language dependant and the other one
is language neutral. This code (trunk patch v5) uses the language dependant part
and the language is hardcoded to 040904b0 (Unicode US English) for quicktime and
040904E4 (ANSI US English) for WMP. This is not good. For correct way of getting
the file version and doing file version comparisons see (for instance) :

http://lxr.mozilla.org/mozilla1.0/source/xpinstall/wizard/windows/uninstall/extra.c#1026

Specifically, all you need is in 3 functions:

GetFileVersion()
TranslateVersionStr()
CompareVersion()

I suggest that you :

1) use TranslateVersionStr() on pref strings
2) use GetFileVersion() to get the file version in a language independant way
3) use CompareVersion() to detect the plugin

This applies to quicktime plugin and WMP plugin





Comment 34 Bernard Alleysson 2002-05-01 08:59:43 PDT
A temporary fix that works for me is to replace the line:
PL_strcpy(wmpVer, GetKeyValue(verbuf, \\StringFileInfo\\040904E4\\FileVersion"));
by 
PL_strcpy(wmpVer, GetKeyValue(verbuf, \\StringFileInfo\\040904b0\\FileVersion"));
in 
mozilla/modules/plugin/base/src/nsPluginDirServiceProvider.cpp

obviously this won't work for anyone but it can help ...









from:
PL_strcpy(qtVer, GetKeyValue(verbuf, "\\StringFileInfo\\040904E4\\FileVersion"));

to:
PL_strcpy(qtVer, GetKeyValue(verbuf, "\\StringFileInfo\\040904b0\\FileVersion"));

Comment 35 Frederic Bezies 2002-05-01 11:28:43 PDT
Plugin import that works in 1st may build (for win32) :

Java RE 1.4.0
Quicktime 5.0.2
Adobe Acrobat

Great !

What about : Real and windows media player ?
Comment 36 scottputterman 2002-05-01 11:35:53 PDT
For NS folks, adding that Bugscape 14100 is a dup of this and should be verified
when this is fixed.
Comment 37 Bernard Alleysson 2002-05-01 12:27:06 PDT
Frédéric:
windows media player is supposed to work !
(See my comments)

what OS and what wmplayer.exe version are you using ?
Comment 38 Peter Lubczynski 2002-05-01 12:45:49 PDT
Created attachment 81903 [details] [diff] [review]
patch v.5.1

Here is a new patch for the trunk. It fixes the problem of language dependancy
when comparing version information on Windows. Please review.
Comment 39 Peter Lubczynski 2002-05-01 12:46:39 PDT
Reopening for new trunk patch
Comment 40 Frederic Bezies 2002-05-01 13:29:56 PDT
In answert to comment #37

Using WinXP, so Windows Media Player 8.0

Copied npdsplay.dll in my mozilla plugins folder.
Comment 41 Bernard Alleysson 2002-05-01 15:21:56 PDT
I've applied the patch and rebuilt
It looks good.

Something strange:
my breakpoints are not hit anymore so I couldn't see the code in action
Are the plugins cached ?
I removed registry.dat with no success

Anyway I have QuickTime and WMP correctly detected. Thanks !

A few remarks reading the code:

1) macros HIDWORD and LODWORD are not used. they can be removed

2) struct structVer:

ULONGLONG can be replaced by WORD safely
"ull" prefix then should be "w"

3) FileExists()

should return a BOOL 
GetFileAttributes() does not return an HRESULT but a DWORD
BOOL != HRESULT

the function should just be
"return GetFileAttributes(szFile) != INVALID_FILE_ATTRIBUTES;"

4) in various places LPSTR should be LPCSTR

5) GetFileVersion()

user ClearVersion() instead of zeroing members
malloc(sizeof(long)*dwLen) should be malloc(dwLen)

6) CopyVersion()

parameter "verBlock ver2" should be "verBlock *ver2"
why push a struct by value on the stack ?
change code accordingly

7) TranslateVersionStr()

strtok: I thought it was evil :-)
why not use strchr() instead ?
and replace atoi64 by atoi if ULONGULONG is now WORD

8) Now I think that verBlock should be a class :-)
Comment 42 Bernard Alleysson 2002-05-01 15:29:06 PDT
just to avoid future mistakes, in comment #1 you write:
pref("plugin.do_4x_PluginScan", true);
but in fact it is (in winpref.js):
pref("plugin.scan.4xPluginFolder", false);
is this correct ?

Comment 43 Peter Lubczynski 2002-05-01 16:20:28 PDT
Created attachment 81939 [details] [diff] [review]
patch v.5.2

Okay, I made half of your changes. Some the compiler didn't like, others (like
strtok) are probably okay in how they are used here. Please review.

Yes, plugins are "cached". You may need to 'touch' them.

Yes, I made a mistake in my comment in the bug. The pref name is indeed
'plugin.scan.4xPluginFolder'.
Comment 44 Peter Lubczynski 2002-05-01 16:22:51 PDT
Created attachment 81940 [details] [diff] [review]
patch v.5.3

oops, forgot to remove the useless macros.
Comment 45 Peter Lubczynski 2002-05-01 17:07:49 PDT
Created attachment 81950 [details] [diff] [review]
patch v.6 (branch patch)

This is a complete patch for the 1.0 branch, merged to the 1.0 tip, with the
changes that are already in the trunk (v.5) and the new changes (v.5.3).
Comment 46 av (gone) 2002-05-01 17:52:08 PDT
Comment on attachment 81940 [details] [diff] [review]
patch v.5.3

I would really like to see all the helper functions for version manipulating
members of some class. I understand we have little time now so at least make
them |static|. With this change and filing a new bug on cleaning this up --
r=av.
Comment 47 av (gone) 2002-05-01 17:53:03 PDT
Comment on attachment 81950 [details] [diff] [review]
patch v.6 (branch patch)

My comments in previous attachment apply here too. r=av.
Comment 48 Peter Lubczynski 2002-05-01 17:59:37 PDT
Created attachment 81954 [details] [diff] [review]
patch 5.4 (trunk patch)

New trunk patch with statics. Will open new bug on making a file version class.
Comment 49 Peter Lubczynski 2002-05-01 18:01:33 PDT
Created attachment 81956 [details] [diff] [review]
patch 6.1 (branch patch)
Comment 50 Peter Lubczynski 2002-05-01 18:01:38 PDT
Created attachment 81957 [details] [diff] [review]
patch 6.1 (branch patch)
Comment 51 Bernard Alleysson 2002-05-02 06:19:23 PDT
Looks good (still) :-)
I've just tried patch 5.4 (trunk patch) on another machine (Windows 2000)
and I can see that WMP, QuickTime, JRE, Flash (from Netscape 4), Acrobat
are all detected in their respective locations.

Comment 52 Marc Attinasi 2002-05-02 10:19:58 PDT
Comment on attachment 81954 [details] [diff] [review]
patch 5.4 (trunk patch)

check the malloc return in
lpData = (LPVOID)malloc(dwLen);
sr=attinasi
Comment 53 Marc Attinasi 2002-05-02 10:21:19 PDT
Comment on attachment 81957 [details] [diff] [review]
patch 6.1 (branch patch)

sr=attinasi
Comment 54 Asa Dotzler [:asa] 2002-05-02 11:05:34 PDT
Comment on attachment 81957 [details] [diff] [review]
patch 6.1 (branch patch)

a=asa (on behalf of drivers) for checkin to the 1.0 branch. (re-approval)
Comment 55 Jaime Rodriguez, Jr. 2002-05-02 12:34:35 PDT
Peter - Pls check this in today, and add the fixed1.0.0 keyword ... and be ADT
free!!! :-)
Comment 56 Peter Lubczynski 2002-05-02 13:54:51 PDT
patch in trunk and 1.0 branch, marking FIXED and adding fixed1.0.0

Thanks all!
Comment 57 Olivier Cahagne 2002-05-02 14:21:48 PDT
sorry for the spam, patch mentions Windows Media Player 7.0.
However, 7.1 is required, 7.0 won't work, see bug 104506.
I might be wrong but I want to be sure as this is to be in release 1.0.
Comment 58 Peter Lubczynski 2002-05-02 14:58:35 PDT
WMP 7.0 WFM on my machine and those I tested. I could not find a bug
specifically on WMP 7.0 (I think bug 66015 is about 6.4 or maybe fixed) not
working so please open a new one so we can track this issue individually and
determine the root cause of this failure.
Comment 59 Frederic Bezies 2002-05-03 08:52:24 PDT
In answer to comment #37 (and final comment for this comment !)

Windows Media Player 8.0 (aka XP) is recognized and working fine with 2002050304
trunk build ;-)
Comment 60 shrirang khanzode 2002-05-03 15:44:09 PDT
Thanks for all the help in verification,guys. This works nicely on today's 
branch 0503 build on winnt/98/xp.
Comment 61 Peter Lubczynski 2002-05-08 08:05:01 PDT
*** Bug 143013 has been marked as a duplicate of this bug. ***
Comment 62 Peter Lubczynski 2002-05-08 10:27:11 PDT
*** Bug 142980 has been marked as a duplicate of this bug. ***
Comment 63 Peter Lubczynski 2002-05-20 14:36:36 PDT
*** Bug 119056 has been marked as a duplicate of this bug. ***
Comment 64 shrirang khanzode 2002-08-12 14:13:21 PDT
works on the trunk as well. (0812)
Comment 65 Clotho 2003-07-31 01:38:18 PDT
Can the patch added to later version of Mozilla?

Note You need to log in before you can comment on or make changes to this bug.