OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Internet => Topic started by: ppgrainbow on 2011.05.11, 04:40:05

Title: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.11, 04:40:05
Has anyone run into this problem lately?

For me, it's been nearly two weeks since I reinstalled OS/2 Warp 4 under Virtual PC 2004 and most recently, I'm starting to have some problems lately.

When I right click on the search engine box whatever it's in Google or Yahoo!, a bunch of dialog boxes corrupt the display, Firefox 4.0.1 crashes and I end up receiving this error message:

SYS3171: A program in this session encountered a problem and cannot continue.

When I click on Display register information, I get the following according to this screenshot: http://imageshack.us/m/12/658/pmmergeerror.png

The error message in this screenshot mentions PMMERGE.DLL and that due to insufficient stack space, the exception was not dispatched. The PMMERGE.DLL file that I'm using is from FixPak 15 (datestamp 19 October 2000, 9:04 PM).

The right click problem does not effect SeaMonkey 2.0.14 (Gecko 1.9.1) and the legacy Mozilla web browser. This only occurs in the latest version of Firefox built under Gecko 2.0.

Is there a way to fix the PMMERGE.DLL problem to make it work properly with Firefox 4?
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: miturbide on 2011.05.11, 05:22:02
Hi

are you using Warp 4.52? any fixpack?
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.11, 06:18:59
Quote from: miturbide on 2011.05.11, 05:22:02
Hi

are you using Warp 4.52? any fixpack?

The latest version of OS/2 Warp that I'm using is Fixpack 15 (Warp v4.5) with the internal revision 14.104_W4 (11 August 2005) and remarkably, Firefox 4 still works.

EDIT: I'm currently in the command prompt and I'm gonna try to replace the version of PMMERGE.DLL with a updated version from July 2001 (46701_FIX.ZIP). If not, then I will try a version of PMMERGE.DLL from 2004. :)

EDIT 2: Neither the updated versions of PMMERGE.DLL worked. The July 2001 version of PMMERGE.DLL had no effect and the 2004 version caused OS/2 to not boot at all. It looks like that I'm gonna be stuck with the version of PMMERGE.DLL until there is a way to fix the right click crashing issue. :(
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.11, 23:33:45
Except as a fix for a specific version, or when you are sure there are no prerequisites, PMMERGE should not be replaced on it's own. For some of the PMMERGE releases, there are other files that are inter-related that need to be replaced as well.

Now, on to the problem at hand. PMMERGE will flake out for a variety of reasons, as it is used by numerous OS/2 subsystems. If something is wrong with a printer driver/subsystem, this will cause your issue when presentation spaces are being created. The same applies to certain video drivers, certain WPS enhancements that are interfering, and too numerous other things to fix.

You can:
- Try removing any/all printer objects
- Ensure no Firefox enhancements are running (such as the REXX stuff)
- Ensure you have no additional DIFFERENT copies of PMMERGE running (not a good thing if the WPS is using one version, while everything else is force-loading another)
- Reinstall FP15 and ensure that PMMERGE (and other related files) are properly processed by the FP installer and locked file handler
- Ensure you are not "mix-and-matching" eCS and Merlin/Aurora/Warp files (re: note above about certain versions of PMMERGE having other upgrade/update pre-requisites).
- Switch to standard GENGRADD SVGA

Kinda vague and non-direct steps, huh?

Sans a need in FF4.0.1 for a specific version of PMMERGE, you'd need to step-through debug the processes to figure out why PMMERGE is crashing.

Here's an interesting read:
http://home.clara.net/orac/os2/pmmerge.htm

From there, you can see just how involved PMMERGE is with... well... almost everything. :(
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.12, 02:34:46
Quote from: RobertM on 2011.05.11, 23:33:45
Except as a fix for a specific version, or when you are sure there are no prerequisites, PMMERGE should not be replaced on it's own. For some of the PMMERGE releases, there are other files that are inter-related that need to be replaced as well.

Now, on to the problem at hand. PMMERGE will flake out for a variety of reasons, as it is used by numerous OS/2 subsystems. If something is wrong with a printer driver/subsystem, this will cause your issue when presentation spaces are being created. The same applies to certain video drivers, certain WPS enhancements that are interfering, and too numerous other things to fix.

You can:
- Try removing any/all printer objects
- Ensure no Firefox enhancements are running (such as the REXX stuff)
- Ensure you have no additional DIFFERENT copies of PMMERGE running (not a good thing if the WPS is using one version, while everything else is force-loading another)
- Reinstall FP15 and ensure that PMMERGE (and other related files) are properly processed by the FP installer and locked file handler
- Ensure you are not "mix-and-matching" eCS and Merlin/Aurora/Warp files (re: note above about certain versions of PMMERGE having other upgrade/update pre-requisites).
- Switch to standard GENGRADD SVGA

Kinda vague and non-direct steps, huh?

Sans a need in FF4.0.1 for a specific version of PMMERGE, you'd need to step-through debug the processes to figure out why PMMERGE is crashing.

Here's an interesting read:
http://home.clara.net/orac/os2/pmmerge.htm

From there, you can see just how involved PMMERGE is with... well... almost everything. :(


Okay. I tried switching to GENGRADD and it wasn't much of a help.

I pulled up this utility called SysInfo/2 and I found that it's still using the S3 Trio32 driver with just 4 MB of video memory. I got OS/2 Warp 4 configured to used 16 MB of video RAM.

The kernel level that I got recently installed is 14.104a, the highest that it will go for OS/2 Warp 4. Internel revision 14.104a is from the most recent WSeB CP2/Warp 4 CP2 postfix. I was wondering if 14.104a is causing problems with the most recent version of Firefox.

If that's the case, I might have to follow your advice and reinstall FixPack 15 to see if the crash goes away and if all of the above isn't helping, I will most likely have to conclude that Firefox 4 (and future versions of Firefox) is NOT 100% compatible with OS/2 Warp 4 running under Virtual PC 2004.

If all else fails, then other alternates would be to revert back to Firefox 3.6. However, if I wanted to use Innotek Java 1.4.2, I would have to revert futher back to Firefox 3.5 (which recently reached end of life after Firefox 4.0.1 was released).

But anyways, Firefox 3.6 worked. At least that I'm experiencing no crashes in relations to right clicking the mouse. :)
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.12, 04:02:53
I'll try it on one of my WSeB  machines tonight.

Questions:
(1) Are you sure the Trio32 supports 16MB? If not, that may be part of the problem.
(2) Is the machine SMP?
(2a) If not SMP, did you ensure you installed the w4 kernel (not the UNI or SMP)?
(2b) If SMP, if the machine was Warp 4 (not WSeB), have you ensured you have updated all of the files that go along with the SMP "add-on"?
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.12, 04:55:12
Quote from: RobertM on 2011.05.12, 04:02:53
I'll try it on one of my WSeB  machines tonight.

Questions:
(1) Are you sure the Trio32 supports 16MB? If not, that may be part of the problem.
(2) Is the machine SMP?
(2a) If not SMP, did you ensure you installed the w4 kernel (not the UNI or SMP)?
(2b) If SMP, if the machine was Warp 4 (not WSeB), have you ensured you have updated all of the files that go along with the SMP "add-on"?

I'm not using WSeB and the machine is not SMP. The W4 kernel, 14.104a that I installed is correct. Unless there are workarounds, it turns out that Firefox 3.6, Seamonkey 2.0.x and any Mozilla product built on Gecko 1.9.2 will most likely be the last release that will work on OS/2 Warp under Virtual PC. However, I may eventually be wrong.

If you have found any issues running Firefox 4 on WSeB, let me know and it'll be taken from there.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.12, 05:38:57
Well then, I wonder if FF4.0.1 is doing something that's making PMMERGE hit something in Ring 2... not sure how decent the implementation is in VPC, but I do know there were problems with its implementation in various other virtualization tools (from flawed support to virtually non-existent support).
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.12, 08:30:20
Quote from: RobertM on 2011.05.12, 05:38:57
Well then, I wonder if FF4.0.1 is doing something that's making PMMERGE hit something in Ring 2... not sure how decent the implementation is in VPC, but I do know there were problems with its implementation in various other virtualization tools (from flawed support to virtually non-existent support).

It seems that Firefox 4 doesn't work too well when it runs on OS/2 under Virtual PC. Simply right-clicking the mouse causes it to crash under VPC 2004 (and even VPC 2007). To make matters even worse, older versions of Firefox might not even run too when running OS/2 under QEMU either since it's much slower than VPC. It seems that the emulated S3 Trio video card with 16 MB of memory may not be capable of running the latest version of Firefox afterall. :(

Not every software works when running OS/2 under Virtual PC or QEMU, ya know.

I don't know if I'll have the time to test Firefox 4 on other operating systems under VPC 2004.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: miturbide on 2011.05.12, 19:26:29
I have also some stability problems with Firefox 4.0 and 4.0.1 running on eCS 2.0 as a guest on Virtualbox 4.0.4. I had already opened a ticket to Mensys (http://bugs.ecomstation.nl/view.php?id=2974). It is trap 000e in OS2KRNL in this case.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.12, 22:34:26
Quote from: miturbide on 2011.05.12, 19:26:29
I have also some stability problems with Firefox 4.0 and 4.0.1 running on eCS 2.0 as a guest on Virtualbox 4.0.4. I had already opened a ticket to Mensys (http://bugs.ecomstation.nl/view.php?id=2974). It is trap 000e in OS2KRNL in this case.

Oh dear, while the problems with Firefox 4 are as bad on OS/2 Warp 4, the situation appears to be much worse on eComStation. I'm gonna try to search for articles on how to get FF4 to work on Warp 4 (under VPC); otherwise, I will eventually be stuck on Firefox 3.6, which will be supported by Mozilla for a very short period of time.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.13, 01:58:21
Hi,

Apologies for not being clear. If various versions of Firefox are making extensive calls to code that OS/2 runs in CPU Ring 2, that may be the problem. I was extremely busy last night so did not have time to test FF4 on WSeB. I will try tonight. I've got one UNI and a couple SMP setups (all running on "bare metal"), and will see what happens.

Ring 2 support isn't the best in some virtualization software. OS/2 is one of the rare operating systems that actually uses the CPU's various protection levels for code, kernel and driver protection. Last I read, the NT line (ie: Windows 7 downward) still make (at best) minimal real use of actual hardware based code protection. As it is, I cannot remember any other OS that uses Ring 2... but it's been a problematic experience.

Anyway, one of the systems I have is running a real-deal S3 (albeit with less memory) and OS/2 is using it via GRADD... so, I will test that implementation as well. I do know that earlier versions (the v3 line and I think even a couple early Minefield versions) ran fine on the S3 in that system, even under SMP.

Best,
Robert
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.13, 04:11:31
Hmmm... for some odd reason, my post from this morning is showing now... oh well.

ok... some things to do and try and some notes:

(1)
The aforementioned Ring 2 issue is not fixable except by those who write the virtualization software. A trap 000e can indeed be related to a privilege issue - namely something that is supposed to be running in Ring 2 flaking out because of poor virtual Ring 2 CPU support.

(2)
It is possible that the virtual machine's virtual hardware caching mechanism (ie: all but the CPU cache) is causing issues. Try disabling the same "real box" cache options that you would disable on a Warp 3 or Warp 4 system for the installation stage. Not sure if this is possible as I have not played with the newer versions of VPC/VirtualBox.

(3)
Check the settings for danis506 and disable all the "advanced" features such as busmastering and such. Under decent load, with a poor implementation, these too can cause a trap 000e. Anyone who remembers early releases of Dani's drivers when certain chipsets had flaky support for various HDD features probably remembers this happening.

(4)
Double-check your memory-conflicting settings in config.sys. The most relevant ones are VIRTUALADDRESSLIMIT, MAXTHREADS and cache settings for JFS (and/or HPFS386) - and possibly those of the swap file.

(5)
IF the virtual BIOS has such settings, disable any advanced features for the S3 card... such as shadow buffering, etc.

Not sure how helpful that is, as I've got no experience on the newer virtualization software, but those are all issues that, under various real hardware scenarios, have caused trap 000e's on Warp, WSeB and eCS.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.13, 07:06:37
Quote from: RobertM on 2011.05.13, 04:11:31
Hmmm... for some odd reason, my post from this morning is showing now... oh well.

ok... some things to do and try and some notes:

(1)
The aforementioned Ring 2 issue is not fixable except by those who write the virtualization software. A trap 000e can indeed be related to a privilege issue - namely something that is supposed to be running in Ring 2 flaking out because of poor virtual Ring 2 CPU support.

(2)
It is possible that the virtual machine's virtual hardware caching mechanism (ie: all but the CPU cache) is causing issues. Try disabling the same "real box" cache options that you would disable on a Warp 3 or Warp 4 system for the installation stage. Not sure if this is possible as I have not played with the newer versions of VPC/VirtualBox.

(3)
Check the settings for danis506 and disable all the "advanced" features such as busmastering and such. Under decent load, with a poor implementation, these too can cause a trap 000e. Anyone who remembers early releases of Dani's drivers when certain chipsets had flaky support for various HDD features probably remembers this happening.

(4)
Double-check your memory-conflicting settings in config.sys. The most relevant ones are VIRTUALADDRESSLIMIT, MAXTHREADS and cache settings for JFS (and/or HPFS386) - and possibly those of the swap file.

(5)
IF the virtual BIOS has such settings, disable any advanced features for the S3 card... such as shadow buffering, etc.

Not sure how helpful that is, as I've got no experience on the newer virtualization software, but those are all issues that, under various real hardware scenarios, have caused trap 000e's on Warp, WSeB and eCS.

For some reason, after you posted your comment, I can't seem to access my own thread. Anyways, let me go through this over..

1. I pretty much admit that Virtual PC doesn't handle Ring 2 too greatly well and TRAP 000E errors are clearly attributed to poor virutal Ring 2 CPU support.

2. As for "real box" caching options, I never heard of it. I don't think that it's possible with Virtual PC 2004 or Virtual PC 2007.

3. I'm not using the DANIS506.ADD driver, I'm using the IBM1S506.ADD. With all of the advanced features turned off, I don't know if replacing it with the DANIS506.ADD will fix the problem or not. As for this parameter in Line 2 of the CONFIG.SYS file:

IFS=C:\OS2\HPFS.IFS /CACHE:2048 /CRECL:4 /AUTOCHECK:CD

The HPFS.IFS driver is only allocating 2 MB of cache, should I (1) modify these values or (2) disable caching alltogether?

4. As for the SWAPPATH and VIRTUALADDRESSLIMIT parameters, I had set a 1 GB (1048576) swapfile and set the virtual address limit to 2 GB (2048)? Should I fix this or leave it alone? The swapfile is placed on the second hard drive under the SWAPPER directory.

MEMMAN=SWAP,PROTECT
SWAPPATH=D:\SWAPPER 1048576 1048576
VIRTUALADDRESSLIMIT=2048

5. The virtual BIOS has no advanced settings for the S3 Trio card at all.

If you found a fix to this problem or if there isn't one, please let me know. I can hardly access the OS/2 World.com website as it has been having problems off and on.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.14, 03:11:30
(1) That will hopefully be a problem that improves for VirtualBox... I have my suspicions... as to why.

(2) In the virtual BIOS, (dsiable) video card cache, system cache (NOT the CPU cache), shadow cache/buffers, ROM/BIOS cache(s). Assuming such settings exist. I have not used the new versions of VPC, so I have no clue which (if any) are still there.

(3a) IBM1S506/Dani... possibly... especially if the partition size is something too large for IBM1S506

(3b) HPFS cache... irrelevant. My suggestion only applies to the HPFS386 cache, which is an entirely different beast (and to the JFS cache).

(4a) How much memory is allocated to the VM? You shouldn't need a swap file of a gig. Try 64MB to 256MB. OS/2 is very efficient at enlarging or shrinking from the preset value (if needed). On my server (with 4GB memory), my swap file is 2MB. Depending on how much "real" memory the OS/2 session sees, a very large initial swap file size may be problematic. Not 100% sure on this one, as it's from memories of far older versions of OS/2, and the kernel has changed considerably since then.

(4b) I use a virtual address limit of 1536 or 1792. With a big enough JFS cache, or a big thread pool, hitting 2048 for that setting will cause problems.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.14, 05:42:39
Re: the swap file.

I believe I am remembering this correctly. The absolute maximum the swap file can be, on ANY iteration of Warp/eCS, is 2GB. Even a byte longer will cause a crash (probably a trap 000e, if my memory of what such an attempt calls).

If for some reason, with a swap file set at 2GB, something tries growing the file, regardless of it being on a JFS partition, this will occur.

Also, if memory serves, the reason for this (unless something has changed very recently) is that the code that handles the swapper.dat file is not capable of handling larger than 2GB files, regardless of underlying file system.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.14, 23:45:25
Quote from: RobertM on 2011.05.14, 05:42:39
Re: the swap file.

I believe I am remembering this correctly. The absolute maximum the swap file can be, on ANY iteration of Warp/eCS, is 2GB. Even a byte longer will cause a crash (probably a trap 000e, if my memory of what such an attempt calls).

If for some reason, with a swap file set at 2GB, something tries growing the file, regardless of it being on a JFS partition, this will occur.

Also, if memory serves, the reason for this (unless something has changed very recently) is that the code that handles the swapper.dat file is not capable of handling larger than 2GB files, regardless of underlying file system.

I will be making adjustments to the SWAPPER.DAT file to reduce the minimum size to 32 MB or even 16 MB at startup. I will also have to make adjustments to the VIRTUALADDRESSLIMIT to make it less than 2 GB or that the OS/2 VM will be more stable.

I have allocated 640 MB of memory with the latest internal revision of OS/2 Warp 4 and ironically, it works. I recall that the original release of OS/2 Warp 4 (and FixPack 15) was not designed to handle more than 512 MB of memory as it will lead either to system instability or even "A unrecoverable processor error has been encountered". I might have to reduce it to 512 MB just to be safe.

As for the IBM1S506.ADD driver, I found that with FP15 and the updates applied, it is capable of supporting hard disks larger than 8,032 MB (7.84 GB) and up to 64 GB per HPFS partition (on hard disks larger than 64 GB). I used the updated installation floppies for hard disks greater than 8.4 GB to install OS/2 Warp 4, btw.

Once that is finished, I will be installing Firefox 4.0.1 under a temporary directory C:\FF.401 to see if the right click crash goes away.

If it does or if it still doesn't, I'll let you know. :)

Update: I tried to reduce the minimum size of the SWAPPER.DAT file to 16 MB, reduced the size of the memory allocated to the VM to 512 MB and reduced the size for the VIRTUALADDRESSLIMIT variable to 1024 and the right click crash issue still exists. I'm still getting the SYS3175 error referencing to PMMERGE.DLL. I'll try to find other ways to fix this issue.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: RobertM on 2011.05.15, 00:09:30
Ah, the confusing world of OS/2... I'll touch on the relevant things...

Quote from: ppgrainbow on 2011.05.14, 23:45:25
Quote from: RobertM on 2011.05.14, 05:42:39
Re: the swap file.

I believe I am remembering this correctly. The absolute maximum the swap file can be, on ANY iteration of Warp/eCS, is 2GB. Even a byte longer will cause a crash (probably a trap 000e, if my memory of what such an attempt calls).

If for some reason, with a swap file set at 2GB, something tries growing the file, regardless of it being on a JFS partition, this will occur.

Also, if memory serves, the reason for this (unless something has changed very recently) is that the code that handles the swapper.dat file is not capable of handling larger than 2GB files, regardless of underlying file system.

I will be making adjustments to the SWAPPER.DAT file to reduce the minimum size to 32 MB or even 16 MB at startup. I will also have to make adjustments to the VIRTUALADDRESSLIMIT to make it less than 2 GB or that the OS/2 VM will be more stable.

Sadly, I don't know the mechanism that handles all swap file access. This will hopefully help.

Quote from: ppgrainbow on 2011.05.14, 23:45:25
I have allocated 640 MB of memory with the latest internal revision of OS/2 Warp 4 and ironically, it works. I recall that the original release of OS/2 Warp 4 (and FixPack 15) was not designed to handle more than 512 MB of memory as it will lead either to system instability or even "A unrecoverable processor error has been encountered". I might have to reduce it to 512 MB just to be safe.

That was actually never the case. But, for most people, it was close enough that people thought it was. Certain hardware never had problems with larger memory amounts (notably numerous IBM workstations and servers in the Intellistation and Netfinity line respectively). Thus, I guess for most people, it's an applicable problem, but not for the reasons they think.

With the current kernel you are running, and assuming you have updated the other files that should have been updated with it, like OS2LDR as one example, you should be able to use a full 4GB (minus address space used for bus resources).

Quote from: ppgrainbow on 2011.05.14, 23:45:25
As for the IBM1S506.ADD driver, I found that with FP15 and the updates applied, it is capable of supporting hard disks larger than 8,032 MB (7.84 GB) and up to 64 GB per HPFS partition (on hard disks larger than 64 GB). I used the updated installation floppies for hard disks greater than 8.4 GB to install OS/2 Warp 4, btw.

The 8GB limitation doesn't exist in Warp 4. FP15 (with LVM) extended partition size support, but to a far higher number. The 64GB limitation, btw, is solely for HPFS drives, thus using JFS alleviates that.

The 8GB limitation (or 1GB, or 2GB or 4GB, depending on card) STILL exists for various SCSI cards. That is due to those cards being limited by it's BIOS' boot capabilities.

Quote from: ppgrainbow on 2011.05.14, 23:45:25
Once that is finished, I will be installing Firefox 4.0.1 under a temporary directory C:\FF.401 to see if the right click crash goes away.

If it does or if it still doesn't, I'll let you know. :)

:) Good luck!
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.15, 01:04:48
I'm starting to find some solutions here. The problem is not OS/2 itself.

I disabled all of the add-ons and readded only the critical ones. Once Firefox 4.0.1 reloaded, I disabled all add-ons and then reenabled one of these addons to determine which add-on causes problems and I concluded that Menu Editor 1.2.7 causes problems with Firefox 4 (and later) under OS/2 and will most likely be incompatible with future versions of Firefox under OS/2 and eCS.

Gosh, I was clueless all along! ;D

(By the way, I kinda feel disappointed to hear that Firefox 4 and later neither supports MacOS X 10.4 [Tiger] nor PowerPC processors.)

And one more thing, as for Java, I'm pretty much stuck on 1.4.2_09 and browsers built on Gecko 1.9.2 (and later) do not work with it. So until there is a workaround to get later versions of Java working with Firefox 4+ and SeaMonkey 2.1, I'm gonna have to use the Mozilla Application Suite (legacy browser).
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: miturbide on 2011.05.18, 19:56:56
Did you installed Menu Editor 1.2.7 a extension?  or comes by default? Because I don't find that on my system.
Title: Re: Problems with Firefox 4.0.1 under OS/2 Warp 4
Post by: ppgrainbow on 2011.05.18, 23:32:37
Quote from: miturbide on 2011.05.18, 19:56:56
Did you installed Menu Editor 1.2.7 a extension?  or comes by default? Because I don't find that on my system.

Yep, I did. I learned that this extension had caused problems when running it in the first place. Now that Menu Editor 1.2.7 has been uninstalled, I can now right click using my mouse without any problems.

Problem solved. :)