OS2 World Community Forum

OS/2, eCS & ArcaOS - General => Events => Topic started by: Neil Waldhauer on March 03, 2018, 06:49:24 pm

Title: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Neil Waldhauer on March 03, 2018, 06:49:24 pm
Well, I missed my chance to ask, but the question I would have asked is this:

What is going on with Firefox? As it stands, I can leave the browser pointed to a modern, active webpage, and after some time, the system will reset. I've been doing this long enough to recognize kernel corruption. Firefox runs the system out of some resource, and the kernel is not protected from such a shortage.

Having solved some of these problems in legacy industrial systems, I know they are challenging to solve. Is there any hope that a future version of Firefox will be more forgiving of system shortages?

Is the problem actually in Firefox?
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Lars on March 03, 2018, 07:09:18 pm
Are you sure it is a Firefox problem ?

Sometimes I have reboots if I just open the Master volume control (volume.exe). And I had it on other occasions starting applications. But I also had occasions where I would get a "page fault" exception in Ring 0 (for which I generated a system dump).
I think there is a fundamental flaw in some very basic system component. That could be the OS virtual memory manager. But it can also be DOSCALL1.DLL as that is used by about any process that is started.
I think the virtual memory manager is the more likely culprit. And it much looks like it is a serialization issue (access not properly serialized on updating memory structures etc.) as it only happens occasionally.
If you have Theseus: run "getws.exe" and watch your system reboot ...


Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 03, 2018, 07:41:42 pm
Mozilla definitely makes things worse, probably due to memory fragmentation and running out of certain types of memory.
I run both SeaMonkey and Thunderbird as I seem to be in charge of them. In eCS, after about 3 days of uptime, I'd open a tab or window and spontaneously reboot. ArcaOS doesn't do this, instead I get freezes, usually in text mode applications such as trying to run rsync to back stuff up, sometimes the desktop and often SM doesn't finish closing. Interestingly, while on dial up and using Injoy, Mozilla apps were continuously crashing on me with problems allocating JS memory. Retiring Injoy fixed that with 4 crashes in 3 months, all when querying the system about fonts.
Mozilla is just getting too big and 32bit Windows has lots of problems with OOM (out of memory) crashes that go away just by running 32 bit Firefox on 64 bit Windows. I understand that Chrome is even worse as it spawns more processes to sandbox various things, so moving to Chromium isn't a simple solution. Our platform is an old design and the designers probably never imagined running stuff like Firefox.

As for crashes when opening the volume control, I had that at one time with the work around that I could load the DOS driver for my sound card first by opening a DOS session and then no crash. Turned out to be a faulty CPU, or at least when I swapped my Cyrix 686 that had overheated a few times due to bad fans, with a real Pentium, the crashes went away as well as all the sys3075's I had with Netscape.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Lars on March 03, 2018, 07:51:59 pm
I would love to believe that. However I also have these problems when I don't run Firefox at all.
But again, memory is the problem. When I run EPM.EXE and subsequently close it, I can observe that it leaves an endless sequence of memory "holes" in upper shared memory. That is due to the fact that the DLL that it loads (ETKE603.DLL) specifies trillions of small memory objects (it contains 234 memory objects: who compiled and linked that stuff ?). And for each memory object, 64 kByte of memory is allocated (even though they are considerably smaller).
When EPM is closed the DLL is unloaded but the fragmentation remains.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: roberto on March 03, 2018, 09:33:00 pm
Well, I recently had problems with firefox 38.8.0, and now firefox 45.5.0 works much better
Lately I have had many errors in the popuplog.os2
It gives me the feeling that if the initial start is good, it does not give me any error. Everything is perfect today.
 The question is how to know if the boot is good.?
Even the error of videos that made me turn off and turn on the Wi-Fi constantly disappeared.
saludos
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 03, 2018, 09:43:57 pm
What type of errors in popuplog.os2?
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: roberto on March 03, 2018, 10:24:49 pm
The last days of popup.log
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 04, 2018, 06:57:38 am
The last days of popup.log

I think it is something like the stack getting clobbered due to a bad crash and all the exception handlers crash, so a cascade of crashes.

Well, I recently had problems with firefox 38.8.0, and now firefox 45.5.0 works much better
Lately I have had many errors in the popuplog.os2
It gives me the feeling that if the initial start is good, it does not give me any error. Everything is perfect today.
 The question is how to know if the boot is good.?
Even the error of videos that made me turn off and turn on the Wi-Fi constantly disappeared.
saludos

You're saying this happens upon boot?
How many programs do you have in your startup folder? Perhaps try moving them all to a different folder and start them manually and see if that helps.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: roberto on March 04, 2018, 10:13:36 am
I think it is something like the stack getting clobbered due to a bad crash and all the exception handlers crash, so a cascade of crashes.
Yes, that is, cascade of crashes.

Quote
You're saying this happens upon boot?
I can not do tests now, because I'm doing a macro backup, which will last me one or two days.
I'm still not sure it's at the start, the problem.
The other option is not to start firefox38 at all.
And the third option is an adjustment in the rar program that I can not believe influences. (-w c: \ var \ tmp)
Quote
How many programs do you have in your startup folder? Perhaps try moving them all to a different folder and start them manually and see if that helps.
I only have  in startup folder, CAD,SAMBA clien, tcpip,usbprt, xcenter y move the cups daemon to other folder.
Saludos
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Neil Waldhauer on March 04, 2018, 04:30:27 pm
Thanks, Dave. That is my problem. Lars shows other problems like that.

Years ago, I tried to get Scott Garfinkle to commit his queue interface fixes. If the system queue table exceeds 64K, the kernel simply overwrites whatever is there. Allocate more than 3000 queues, and you can write anything on the kernel you want.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Ian Manners on March 04, 2018, 05:00:47 pm
Quote
What is going on with Firefox? As it stands, I can leave the browser pointed to a modern, active webpage, and after some time, the system will reset. I've been doing this long enough to recognize kernel corruption. Firefox runs the system out of some resource, and the kernel is not protected from such a shortage.

I back leveled libcx0.dll to libcx-0.6.0-1.oc00.i686.rpm and libc066.dll to libc-0.6.6-32.i686.rpm in an attempt to get Apache2 to run on my non server OS/2 and noticed the computer stopped being able to access the HD, leading to a PC I had to physically turn off. Took me a while to figure out it was the backleveling that did it as I'd previously had a dodgy SATA cable cause similiar problems. I also noticed as soon as I went to utube, bang, the video would start playing, sort of, but I couldn't do anything after that point apart from a cold boot, should have twigged on then it was a resource problem and not a hardware problem.

Replacing both libcx0 and libc066 to the latest versions (which I'd backed up, from libcx-0_6_1-2* and libc066.dll from a testcase one in Jan 2018) appears to have fixed this problem. You might like to try the same as I'm use to using Openoffice, firefox v45.9.0-2, and several other apps at the same time with no problems, including viewing (and mostly downloading) utube videos and university videos from Echo/Blackboard.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 04, 2018, 07:22:12 pm

Replacing both libcx0 and libc066 to the latest versions (which I'd backed up, from libcx-0_6_1-2* and libc066.dll from a testcase one in Jan 2018) appears to have fixed this problem. You might like to try the same as I'm use to using Openoffice, firefox v45.9.0-2, and several other apps at the same time with no problems, including viewing (and mostly downloading) utube videos and university videos from Echo/Blackboard.

Yes, the development of Mozilla and libc, libcx has gone hand in hand and need to be the latest versions for running the latest builds of Firefox.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 04, 2018, 07:39:09 pm

Replacing both libcx0 and libc066 to the latest versions (which I'd backed up, from libcx-0_6_1-2* and libc066.dll from a testcase one in Jan 2018) appears to have fixed this problem. You might like to try the same as I'm use to using Openoffice, firefox v45.9.0-2, and several other apps at the same time with no problems, including viewing (and mostly downloading) utube videos and university videos from Echo/Blackboard.

Yes, the development of Mozilla and libc, libcx has gone hand in hand and need to be the latest versions for running the latest builds of Firefox.

I was doing some testing  using pmdll.  One thing I noticed is that firefox, seamonkey, and thunderbird all have different dates on some dlls.  Seamokey has the latest versions.  I renamed the originals and replaced them with the ones from Seamonkey.  Firefox accepted the latest versions, but thunderbird would fail, not run.  The dlls were lgplibs.dll and mozsqlt3.dll.  I replaced and Firefox 45.9.0 is still working great.  I did not need to revert bacl to the originals.  These are from seamonkey version 2.42.9.

yum install firefox

or

http://hobbes.nmsu.edu/download/pub/os2/apps/internet/www/browser/firefox-45.9.0-2.en-US.os2.zip

https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2_exp2.zip

David
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 04, 2018, 10:31:58 pm
I was doing some testing  using pmdll.  One thing I noticed is that firefox, seamonkey, and thunderbird all have different dates on some dlls.  Seamokey has the latest versions.  I renamed the originals and replaced them with the ones from Seamonkey.  Firefox accepted the latest versions, but thunderbird would fail, not run.  The dlls were lgplibs.dll and mozsqlt3.dll.  I replaced and Firefox 45.9.0 is still working great.  I did not need to revert bacl to the originals.  These are from seamonkey version 2.42.9.

Interesting.
Most of the code is shared between FF, SM and TB with most of the code living in mozilla\ where Firefox is built from and Bitwise is in charge of. In theory all these DLLs should be interchangeable, even xul.dll mostly, at least until you do something specific like try to open the settings/preferences.
I haven't uploaded a new TB in a while, mostly due to the latest changes not having much affect on TB so I guess that is why the DLLs didn't work, still there hasn't been any changes to sqlite3 and the only change made to lgpllibs was a while back to fix a bug dynamically loading the FFmpeg DLLs. I've also been experimenting with building with GCC 5.1.0, so SM is built with a different compiler version then FF and IIRC, TB.
I"ll rebuild TB and upload a new version over the next couple of days. It takes close to 10 hours to build TB here on my old gutless machine and often freezes after about 9 hours so I don't rebuild often.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 04, 2018, 10:41:32 pm
I was doing some testing  using pmdll.  One thing I noticed is that firefox, seamonkey, and thunderbird all have different dates on some dlls.  Seamokey has the latest versions.  I renamed the originals and replaced them with the ones from Seamonkey.  Firefox accepted the latest versions, but thunderbird would fail, not run.  The dlls were lgplibs.dll and mozsqlt3.dll.  I replaced and Firefox 45.9.0 is still working great.  I did not need to revert bacl to the originals.  These are from seamonkey version 2.42.9.

Interesting.
Most of the code is shared between FF, SM and TB with most of the code living in mozilla\ where Firefox is built from and Bitwise is in charge of. In theory all these DLLs should be interchangeable, even xul.dll mostly, at least until you do something specific like try to open the settings/preferences.
I haven't uploaded a new TB in a while, mostly due to the latest changes not having much affect on TB so I guess that is why the DLLs didn't work, still there hasn't been any changes to sqlite3 and the only change made to lgpllibs was a while back to fix a bug dynamically loading the FFmpeg DLLs. I've also been experimenting with building with GCC 5.1.0, so SM is built with a different compiler version then FF and IIRC, TB.
I"ll rebuild TB and upload a new version over the next couple of days. It takes close to 10 hours to build TB here on my old gutless machine and often freezes after about 9 hours so I don't rebuild often.

Using PMSeek, all the file dates and sizes were different with Seamonkey containing the latest file dates.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Neil Waldhauer on March 05, 2018, 06:47:32 pm
The transcript of BWW speakup is now up on the VoiCE website. I can see that the topic never came up.

I'm not looking for a "resolution" to problems with Firefox -- I have all the latest libraries on both eCS and ArcaOS. I know there is a lot of work going on by looking at checkins on github, but I don't know the goal of those checkins.

I will say that marking code to load high does make some difference to stability, and I'll comment again on this in a few weeks when I have more information. I think the highmem tool could be a little more user-friendly.

I don't think I can enter a bug report for "what are you guys trying to do with Firefox?"

Silvan said in the speakup that a browser is essential to the life of the operating system. How essential is a web browser to the success of the operating system? I can browse on a smartphone or tablet. There is no platform with a bug-free browser. Still, I'm inclined to think he's right. I'm using Firefox on ArcaOS to type this message.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 05, 2018, 07:20:23 pm
Firefox does what I call CPU trashing.  Based on the CPU monitor, it is extremely high.  Seamonkey does te same thing, but is nowhere near as high as Firefox. Right now I will use Seamonkey since it does a better job utilizing the CPU.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 06, 2018, 12:52:30 am
Hi, currently Bitwise is trying to get all of the Mozilla testsuite to run and pass, not a small job as it hasn't even worked since about FFv4 when Walter did a lot of work on it. The testsuite is what Mozilla expects to pass before releases and even after new commits.
So far, he has fixed a couple of memory related problems including fixes to libc and/or libcx and moved from mmap to native memory allocation in places. There's no way to say if running the testsuite will show our problems but it is a good start.
Currently dmik is trying to implement some type of tracing to see where the code is spending its time. Hopefully that'll help but Mozilla uses lots of JS, XUL and such to draw the browser so who knows.

As for SM being currently faster then FF, it is probably a newer build depending on which FF is used. I was also experimenting with different compiler options, eg optimizing for size rather then speed, which may be why the DLLs were different sizes. Unluckily enough time has gone by that I forget exactly what I did. about:buildconfig will show the compiler flags I (and dmik) used with -Os being for size and -O3 for speed. Probably best is -O3 for the JavaScript engine and -Os for the rest, smaller binaries take less memory.

Here I find that SM performance is great if started in safe-mode and as extensions are enabled, it gets worst, especially some extensions. TB is worse and just mouse overing it can peak both cores for seconds.

A lot of these problems are possibly intrinsic to the design of Mozilla and that is one reason that they're moving to the Quantum rendering engine. Other things are getting worse with all browsers as they split it into multiple processes for various reasons, mostly security.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 06, 2018, 01:55:12 am
I had to move back to Firefox.  Seamonkey would run for awhile and then would suddenly terminate.

What is wierd is that on my lastest bootup, Firefox CPU trashing is way down,  I can't explain it.  Before I could barely use Firefox.  Right now it is pleasant to use.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Doug Bissett on March 06, 2018, 03:53:44 am
There are two things, that I find will help Firefox (and probably the other Mozilla variants). One is to use a small cache. I set it to 50 MB. Of course, individual setups may work better with other sizes.

The other is to use ANPM (RPM/YUM) to install FFMPEG. be careful there because FFMPEG will want to install the sdl (lower case) package, while other things need the SDL (upper case) package. Install SDL (upper case) first. If you already have sdl (lower case) installed, uninstall it (and watch what other packages get uninstalled with it). Then install SDL, and the other packages that got uninstalled, then install FFMPEG.

Those are not going to make FF work perfectly, but I find that it helps.

Quote
I can't explain it.  Before I could barely use Firefox.  Right now it is pleasant to use.

It is possible, that you got a bad web page into the cache, and going back to that web page would try to load the bad page. Eventually, that bad page would work it's way out of the cache, fixing the problem. I try to remember to clear the cache, after a crash.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 06, 2018, 05:19:49 am
Usually a crash or hang will invalidate the whole cache.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Doug Bissett on March 06, 2018, 06:44:23 am
Quote
Usually a crash or hang will invalidate the whole cache.

Perhaps that is what it is supposed to do, but it is my experience, that whatever caused the crash is cached, and FF tries to go back to it, causing another crash. What i try to do, is force it to the default home page, ASAP after the program starts, then go and clear the cache, before going anywhere else. Sometimes, a crash might invalidate the cache, but that is rare, from what I see. A hang never invalidates anything.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 06, 2018, 06:56:08 am
I have lots of experience with depending on the cache, and after a crash, every page needs to be reloaded. On dial-up I got into the habit of very frequent backups and restores after a crash to avoid having to reload everything, at least here with my usual profile and SM.
Guess it is possible that FF acts different but I doubt it, could be a profile thing.
Next time you have a crash, look before restarting the browser and the cache should have been renamed to something like cache.trash1234567890 with random numbers. If not, it's a bug. After starting it should delete the trash cache and build a new one.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 06, 2018, 01:54:02 pm
I have noticed that the amount of CPU trashing changes with sites one goes to.  OS2World home page is low.  This other site is low

http://ecsoft2.org/

However when I go this another web page at the same site, the CPU usage goes up trememndously.

http://ecsoft2.org/popular

Go back to to the home page and it drops tremendously.  So it appears to be certain web pages that cause these browsers to go bonkers.  So what is it about sites such as this that cause the browsers to overreact?

I wonder if it is possible to build into Firefox or Seamonkey the ability to use another caching program such as Oops.  On a properties page select external cache program and have a text box to point it to it, similar to what FM/2 and PMMail do for for external editors.

ftp://hobbes.nmsu.edu/pub/os2/apps/internet/www/server/oops-1-5-24.zip
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 06, 2018, 05:00:24 pm
I have noticed that the amount of CPU trashing changes with sites one goes to.  OS2World home page is low.  This other site is low

http://ecsoft2.org/

However when I go this another web page at the same site, the CPU usage goes up trememndously.

http://ecsoft2.org/popular

Go back to to the home page and it drops tremendously.  So it appears to be certain web pages that cause these browsers to go bonkers.  So what is it about sites such as this that cause the browsers to overreact?

Likely just whatever JavaScript they're running, and some run a lot. Hopefully Bitwise will figure it out
Quote
I wonder if it is possible to build into Firefox or Seamonkey the ability to use another caching program such as Oops.  On a properties page select external cache program and have a text box to point it to it, similar to what FM/2 and PMMail do for for external editors.

ftp://hobbes.nmsu.edu/pub/os2/apps/internet/www/server/oops-1-5-24.zip

Sure, oops or squid are easy to use with Firefox or SeaMonkey as they're just proxies.
For SM for example, you'd install oops including creating its cache and adding it the startup folder or such so it is always running, and then Edit-->Preferences-->Advanced-->Proxies-->Manual proxy configuration: and put in localhost (or 127.0.0.1) and the correct port number, such as 3128.
Even on dial up, using oops or squid didn't seem to make much difference and with more sites becoming HTTPS, they have a harder time caching everything.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 08, 2018, 08:36:29 pm
I was looking at a utility called highmem

http://www.os2site.com/sw/dev/util/highmem-20140406-os2.zip

Its developer "Yuri Dario (Paperino)" states the following:

"Loading code high should almost always be ok. That's because loading code high is mostly transparent to applications: it's the kernel's job to map high addresses to the physical memory where the code resides. Unless some code tries to map a linear code address (aka: a function pointer) to a segmented code address, see below but that does not happen very often.

For loading data high this is much more critical: of course, the same applies as for code but remember "thunking"? A lot of APIs make the silent assumption that a linear data address can be easily mapped to a segmented address and vice versa by a simple well known "thunking" algorithm. However that algorithm only works for "low memory". And OS/2 has enough 16-bit code in its bowels that can only access data via a segmented data address. If you have a big application like Firefox you never know if there is some low level OS component that makes that simple assumption, thunks a data address and subsequently gets it wrong if "high memory" data addresses are used."

This looks like what Firefox is doing. 
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 08, 2018, 08:45:34 pm
We've been pretty careful to make sure any 16 bit API is called from low memory. Doesn't mean it doesn't happen but it sure happens a lot less then when this move to high memory started.
Unluckily, there are also problems in the kernel with high loaded code and data. Most of the recent kernels have been attempts to fix this but without the source code and the right to rebuild and distribute fixes kernels...
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 14, 2018, 07:00:06 pm
I made a STARTUP.CMD file and put it into my ArcaOS 5.02 root directory.

@ echo off
x:
md temp
exit

which creates a temp directory on drive X which is my RAM drive.

I then changed my config.sys to point to where my new temporary directory is located.

SET TMP=x:\\temp
SET TEMP=x:\temp
SET TMPDIR=x:\temp

Now the problem.

My Firefox 45.9.0 download directory in Options points to

f:\home\temp

When I download a file, it always fails.  When I click the retry, it shows it finishes the download.

However,the downloaded file is not found in the f:\home\temp directory.

I now find it in my X:\temp directory.

Before, Firefox would have no problem downloading and the downloads would always be found in the home\temp directory.

Have I done something wrong or is this a problem with Firefox?
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: ivan on March 14, 2018, 07:22:15 pm
Out of interest make a 'F:\home\download' directory and point the firefox downloads to that.  If it works everything is good.

I think the problem could be in the way the temp setting is handled.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 14, 2018, 07:30:47 pm
I made a mistake.  Firefox points to the download directory which is in the home directory. The download directory does exist. 
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: Dave Yeo on March 14, 2018, 10:48:36 pm
I made a STARTUP.CMD file and put it into my ArcaOS 5.02 root directory.

@ echo off
x:
md temp
exit

I'd suggest
x:
if not exist x:\temp mkdir \temp
exit
As at least here, after a warm reboot, all files are still present on the ramdisk and IIRC, trying to create an existing directory causes an error.
Quote
which creates a temp directory on drive X which is my RAM drive.

I then changed my config.sys to point to where my new temporary directory is located.

SET TMP=x:\\temp
Is this typo also in your config.sys?
Quote
SET TEMP=x:\temp
SET TMPDIR=x:\temp

Now the problem.

My Firefox 45.9.0 download directory in Options points to

f:\home\temp

When I download a file, it always fails.  When I click the retry, it shows it finishes the download.

However,the downloaded file is not found in the f:\home\temp directory.

I now find it in my X:\temp directory.

Before, Firefox would have no problem downloading and the downloads would always be found in the home\temp directory.

Have I done something wrong or is this a problem with Firefox?

Sometimes it seems hard to get changes to the download directory to stick. Try pointing it elsewhere and then try putting it back.
BTW, Firefox also has problems downloading to the root of a drive.
Title: Re: Firefox problem, was Re: IRC speakup with BWW this Saturday (3 of March)!
Post by: David Graser on March 15, 2018, 06:21:25 pm
Hi Dave

Thank you for the suggestions.

I changed my Startup.cmd as you suggested.  Works great.

That was a typo in my config.sys that I corrected.

Made the two changes and Firefox download works as it should. 

Thanks for your help.

David