Firefox and Sound
Rich Walsh
Firefox. I've created a new test version that contains a fix for
the issue (I hope) as well as a new feature that should provide a
good stress-test for the fix. You can get it from:
http://e-vertise.com/warpzilla/firefox-3.7a1pre.zip
The Fix: previously, FF would constantly load & unload the MMOS2
dlls. Now it doesn't load them until it's actually about to play
a sound. Once loaded, they stay loaded until you close the browser.
If you don't use the new feature (or ogg support or Flash), they'll
never be loaded.
The Feature: you can now have Firefox play sounds when certain
"events" occur (e.g. a warning dialog pops up). To activate this
feature run MozSounds.cmd from FF's main directory. It's an inter-
active REXX script that adds (or deletes) your choice of Mozilla
events to the WPS Sound object. Thereafter, you can configure
Mozilla sounds from the Sound object the same way you'd set any
system sound.
Notes:
1) To avoid frequent delays, Firefox caches its list of event
sounds. If you enable/disable/change a sound while it's running,
you'll have to restart the browser for the change to take effect.
2) Firefox ignores the Sound object's "Enable system sounds" option.
To silence an event without deleting it from the list, enter an
invalid path for the sound file. For example, the first time you
run MozSounds.cmd, it assigns "x:\MMOS2\SOUNDS\" to each event.
The result is that all the events you added are present but silent.
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
tho...@antispam.ham
> There was a discussion recently about sound problems after opening
> Firefox.
There were two discussions that, to me, looked like they were
about the same problem, but my suspicion was never confirmed.
Marcel talked about problems with PM123 and DLLs that depend
on MDM.DLL, which is part of MMOS2. So his posting involved
multimedia support, which could mean audio, but not necessarily.
I specifically mentioned my audio being killed by certain
versions of Firefox, or perhaps certain combinations of web
pages and Firefox.
> I've created a new test version that contains a fix for
> the issue (I hope) as well as a new feature that should provide a
> good stress-test for the fix.
Now I'm confused, because Dave Yeo reported that he thought the
problem Marcel talked about had been fixed in the latest dailies,
though he also mentioned something about a kernel bug, thus a
true fix would seem to involve the kernel being modified, not
Firefox. Maybe Dave was referring to a workaround in Firefox?
And Marcel went on to confirm that the behavior he had noticed
did not show up in the 3.5.3 pre version.
So does your test version involve a different fix then what
apparently showed up in the latest dailies? Following Marcel's
report, I tried to get the latest 3.5.3 pre version to see if
it solved my problem with audio, but the Warpzilla site only
had a link to 3.5.4, which didn't have anything for download
until today.
> You can get it from:
>
> http://e-vertise.com/warpzilla/firefox-3.7a1pre.zip
Okay, I've now got it, along with the latest 3.5.4 build.
Trying to decide which to test first! Because the problem
would sometimes appear only after several days, the test
won't be fast.
> The Fix: previously, FF would constantly load & unload the MMOS2
> dlls. Now it doesn't load them until it's actually about to play
> a sound. Once loaded, they stay loaded until you close the browser.
> If you don't use the new feature (or ogg support or Flash), they'll
> never be loaded.
How does Firefox 2 differ from Firefox 3 in this regard? I kept
falling back to Firefox 2 whenever I encountered the audio problem
with the latest Firefox 3 version. I just did a quick PSTAT and
looked for MDM.DLL, and the only process that is using it is
Warpmix, even though I do have Firefox 2 running. I've avoided
using Flash because it seemed to be too unstable.
It's unclear to me how "The Fix" actually fixes the problem.
Seems like it will avoid the problem if I never use sound, but
if I encounter a web page that tries to play a sound and the
MMOS2 DLLs get loaded, might the problem simply be delayed
until I close the browser?
> The Feature: you can now have Firefox play sounds when certain
> "events" occur (e.g. a warning dialog pops up). To activate this
> feature run MozSounds.cmd from FF's main directory. It's an inter-
> active REXX script that adds (or deletes) your choice of Mozilla
> events to the WPS Sound object. Thereafter, you can configure
> Mozilla sounds from the Sound object the same way you'd set any
> system sound.
>
> Notes:
> 1) To avoid frequent delays, Firefox caches its list of event
> sounds. If you enable/disable/change a sound while it's running,
> you'll have to restart the browser for the change to take effect.
>
> 2) Firefox ignores the Sound object's "Enable system sounds" option.
> To silence an event without deleting it from the list, enter an
> invalid path for the sound file. For example, the first time you
> run MozSounds.cmd, it assigns "x:\MMOS2\SOUNDS\" to each event.
> The result is that all the events you added are present but silent.
System sounds were an interesting novelty when they first appeared,
but I tired of noise when windows opened and closed and eventually
disabled all system sounds. I might consider selectively enabling
an event here or there.
Rich Walsh
> Rich Walsh writes:
> > I've created a new test version that contains a fix
>
> Now I'm confused, because Dave Yeo reported that he thought the
> problem Marcel talked about had been fixed in the latest dailies,
The incessant loading & unloading of mdm.dll may have been
commented-out - I'm not sure.
> though he also mentioned something about a kernel bug, thus a
> true fix would seem to involve the kernel being modified, not
> Firefox.
Well, if an app loads a dll a gazillion times & fails to notice
that its attempts to unload it have failed (which is what I'd see
in debug builds), then it's possible that either the kernel's
in-use counter or some counter in the dll itself might overflow,
causing who-knows-what kind of errors.
> And Marcel went on to confirm that the behavior he had noticed
> did not show up in the 3.5.3 pre version.
That just suggests that mdm.dll isn't being loaded over & over.
> So does your test version involve a different fix then what
> apparently showed up in the latest dailies?
The difference is in scope, not kind. Like I said, both dlls
(mdm & mmio) are loaded just once - only when actually needed,
not when they _might_ be needed - and they're never unloaded.
Note that they're dynamically loaded and not statically linked
solely to enable some hypothetical user who has removed MMOS2
to retain use of the mozilla apps.
> > You can get it from:
> > http://e-vertise.com/warpzilla/firefox-3.7a1pre.zip
>
> Okay, I've now got it, along with the latest 3.5.4 build.
> Trying to decide which to test first! Because the problem
> would sometimes appear only after several days, the test
> won't be fast.
v3.5.4 is largely a known entity, while v3.7a1pre contains some
significant architectural changes. In addition to my relatively
minor changes to sound, it would be helpful to hear about its
overall performance - in particular, are the windows belonging
to plugins displayed properly?
> How does Firefox 2 differ from Firefox 3 in this regard?
Dunno... FF2 may not have had any sound support, neatly
side-stepping the issue.
> > The Feature: you can now have Firefox play sounds when certain
> > "events" occur (e.g. a warning dialog pops up).
>
> System sounds were an interesting novelty when they first appeared,
> but I tired of noise when windows opened and closed and eventually
> disabled all system sounds. I might consider selectively enabling
> an event here or there.
If I weren't testing this, I wouldn't have any of them enabled!
I'm no fan of system sounds but it's a feature that's available
on other platforms, so I implemented it (plus, I was bored). If
this ever makes it into Seamonkey or Thunderbird, the "new mail"
event might be worth enabling.
tho...@antispam.ham
> Well, if an app loads a dll a gazillion times & fails to notice
> that its attempts to unload it have failed (which is what I'd see
> in debug builds), then it's possible that either the kernel's
> in-use counter or some counter in the dll itself might overflow,
> causing who-knows-what kind of errors.
Assuming one visits a web page that triggers the use of audio,
would launching and closing Firefox a gazillion times have the
same effect on the system that the current version has?
> The difference is in scope, not kind. Like I said, both dlls
> (mdm & mmio) are loaded just once - only when actually needed,
> not when they _might_ be needed - and they're never unloaded.
Until the application closes, when the system does it, right?
> Note that they're dynamically loaded and not statically linked
> solely to enable some hypothetical user who has removed MMOS2
> to retain use of the mozilla apps.
I'm confused again. When I build a number-crunching program for
use by somebody else, I always link statically so that all the
necessary library code is included, just in case the somebody
else doesn't have the necessary libraries. What you said sounds
like just the opposite.
> v3.5.4 is largely a known entity, while v3.7a1pre contains some
> significant architectural changes. In addition to my relatively
> minor changes to sound, it would be helpful to hear about its
> overall performance - in particular, are the windows belonging
> to plugins displayed properly?
The first thing I noticed is that the double bolding associated
with -- what's it called, Workplace Sans font -- isn't occurring
anymore. Nice.
The next thing I tested was the Sudoku puzzles at brainbashers.com.
With Firefox 2, CPU usage while working on the puzzle remained
extremely low, but with Firefox 3, CPU usage would be up around
60 or 70 percent. With the 3.7 pre-alpha, I noticed that the
amount of CPU usage depended on the amount of zoom, which probably
explains why Firefox 2 didn't exhibit the problem. When zoom was
used in Firefox 2, only the text was made larger, not the graphics,
so I couldn't practically use zoom with the Sudoku puzzles. But
because Firefox 3 does make the whole thing larger, I do use the
zoom, which makes positioning of the mouse cursor in the grid
easier when the pencil marks option is turned on. As soon as the
puzzle is completed, CPU usage dropped to essentially zero. I
don't know what the CPU is doing with a mostly static image (there
is a timer updating on the screen, so there is one non-static item).
The next thing I tested is whether Firefox could download a large
file. With Firefox 2, I tried to download a file listed as being
4.03 GB in size, but the download manager said it was only 78.8 MB.
After inquiring with the owner of the file, I was informed that
the file size is 78.8 MB in excess of 4 GB, so apparently we're
running into a file size issue with Firefox 2. I told him that
I'd give it a try on Firefox 3.7, which I did. Same problem.
But 3.7 has an additional problem: right-clicking on the link to
the file produces the expected pop-up menu. I selected the
"Save Link As..." option, which opens the filename dialog, chose
my desired destination directory and clicked on OK. But nothing
happened. No download occurred. So I left-clicked on the link,
clicked on Stop (to avoid having Firefox try to download and
display 4 GB of data), and then used Ctrl+S to save the page,
which is when the Download Manager appeared and said that the
file is only 78.8 MB in size. So the right-click method is
currently broken in addition to the file size issue.
> If I weren't testing this, I wouldn't have any of them enabled!
> I'm no fan of system sounds but it's a feature that's available
> on other platforms, so I implemented it (plus, I was bored). If
> this ever makes it into Seamonkey or Thunderbird, the "new mail"
> event might be worth enabling.
That was the one event that I was thinking about when I said that
I might selectively enable system sounds.
So far, no problems with my audio.
Rich Walsh
> Rich Walsh writes:
>
> > Well, if an app loads a dll a gazillion times & fails to notice
> > that its attempts to unload it have failed (which is what I'd see
> > in debug builds), then it's possible that either the kernel's
> > in-use counter or some counter in the dll itself might overflow,
> > causing who-knows-what kind of errors.
>
> Assuming one visits a web page that triggers the use of audio,
It wasn't visiting a web page that triggered the the dlls to be
loaded & unloaded. It was displaying a menu, clicking on an item
in that menu, etc, that caused the load/unload. IOW, any of the
7 events listed in MozSounds.cmd.
> would launching and closing Firefox a gazillion times have the
> same effect on the system that the current version has?
By "current", I assume you mean 3.5.2 and before. When an app
closes, the the kernel should decrement a dll's use count by the
number of loads that app performed. Whether it actually does is
another matter.
> > The difference is in scope, not kind. Like I said, both dlls
> > (mdm & mmio) are loaded just once - only when actually needed,
> > not when they _might_ be needed - and they're never unloaded.
>
> Until the application closes, when the system does it, right?
Correct.
> > Note that they're dynamically loaded and not statically linked
> > solely to enable some hypothetical user who has removed MMOS2
> > to retain use of the mozilla apps.
>
> I'm confused again. When I build a number-crunching program for
> use by somebody else, I always link statically so that all the
> necessary library code is included, just in case the somebody
> else doesn't have the necessary libraries. What you said sounds
> like just the opposite.
You're not familiar with how dlls work? The actual code is never
linked into the app, only references to entry points in the dll.
By "statically linked", I meant that these references are exposed
in the Imports list and are resolved at load-time - if the dll or
specified entry points in it can't be found, the app fails to load.
By "dynamically linked", I meant that the dll is loaded and its
entry points are resolved programmatically. If there are errors,
the app can deal with it and still run successfully - albeit without
whatever features the dll provides.
> > v3.5.4 is largely a known entity, while v3.7a1pre contains some
> > significant architectural changes. In addition to my relatively
> > minor changes to sound, it would be helpful to hear about its
> > overall performance - in particular, are the windows belonging
> > to plugins displayed properly?
>
> The first thing I noticed is that the double bolding associated
> with -- what's it called, Workplace Sans font -- isn't occurring
> anymore. Nice.
Peter did some work on synthetic emboldening about a month ago.
> The next thing I tested is whether Firefox could download a large
> file. With Firefox 2, I tried to download a file listed as being
> 4.03 GB in size, but the download manager said it was only 78.8 MB.
> After inquiring with the owner of the file, I was informed that
> the file size is 78.8 MB in excess of 4 GB, so apparently we're
> running into a file size issue with Firefox 2. I told him that
> I'd give it a try on Firefox 3.7, which I did. Same problem.
We'll have to look into whether the OS/2 code provides large file
support. BTW... this is an excellent example of where you'd
resolve entry points dynamically rather than at load time. Only
the Warp 4.5 kernel provides this support. If you let the loader
think you need these entry points, then none of the mozapps would
run under the 4.0 kernel.
> But 3.7 has an additional problem: right-clicking on the link to
> the file produces the expected pop-up menu. I selected the
> "Save Link As..." option, which opens the filename dialog, chose
> my desired destination directory and clicked on OK. But nothing
> happened. No download occurred. So I left-clicked on the link,
> clicked on Stop (to avoid having Firefox try to download and
> display 4 GB of data), and then used Ctrl+S to save the page,
> which is when the Download Manager appeared and said that the
> file is only 78.8 MB in size. So the right-click method is
> currently broken in addition to the file size issue.
I tried this with several small files and had no problems at all.
Did you also try this with smaller files? It should come as no
particular surprise that if one aspect of large file support is
broken, the other parts may be as well.
> So far, no problems with my audio.
You won't really know until you've associated some sound with
menu popups and menu execute, then endured the noise as long
as you can. Like I said, this is a stress test :-)
Dave Yeo
> But 3.7 has an additional problem: right-clicking on the link to
> the file produces the expected pop-up menu. I selected the
> "Save Link As..." option, which opens the filename dialog, chose
> my desired destination directory and clicked on OK. But nothing
> happened. No download occurred.
This works fine for me with a build that is very close to Rich's. Did
you try with a file that was less then 2 GB's? I wouldn't be surprised
if there is no large file support.
Dave
Dave Yeo
>> I'm confused again. When I build a number-crunching program for
>> > use by somebody else, I always link statically so that all the
>> > necessary library code is included, just in case the somebody
>> > else doesn't have the necessary libraries. What you said sounds
>> > like just the opposite.
> You're not familiar with how dlls work? The actual code is never
> linked into the app, only references to entry points in the dll.
> By "statically linked", I meant that these references are exposed
> in the Imports list and are resolved at load-time - if the dll or
> specified entry points in it can't be found, the app fails to load.
> By "dynamically linked", I meant that the dll is loaded and its
> entry points are resolved programmatically. If there are errors,
> the app can deal with it and still run successfully - albeit without
> whatever features the dll provides.
>
Terminology, statically linked usually means linked against the actually
object files, often compressed into an AR archive (much like a TAR).
Its late and I have had a couple of beers so I can't think of a better
terminology and I understand what you mean but statically linked has a
well defined meaning and it is not dynamically loading the DLL.
Dave
Pierre Jelenc
>
> http://e-vertise.com/warpzilla/firefox-3.7a1pre.zip
It solves the problem I had with Z!, namely that after running FF (and
closing it) Z! would not work and the diagnosis I got was that Z! was not
finding an MMOS2 DLL that was in fact there.
I thought that it had also solved the problem of FF using enormous amounts
of CPU time, often in the 70-80% range. This version starts very low (like
SeaMonkey on similar sites, between 2 and 15%) but after a few minutes CPU
usage suddenly jumps to 98-100% and stays there, essentially making the
whole system unusable. If I close FF, either normally or by killing it via
CAD-popup, the CPU usage stays around 100% for about 2 minutes, while
there is some intermittent churning of the hard drive, then it finally
drops to a normal level.
There do not seem to be any evil remnants once FF has been thoroughly
killed, and the system works just fine. FF is pretty much unusable,
however, because of that high CPU usage.
Pierre
--
Pierre Jelenc
The Gigometer www.gigometer.com
The NYC Beer Guide www.nycbeer.org
tho...@antispam.ham
>>> Well, if an app loads a dll a gazillion times & fails to notice
>>> that its attempts to unload it have failed (which is what I'd see
>>> in debug builds), then it's possible that either the kernel's
>>> in-use counter or some counter in the dll itself might overflow,
>>> causing who-knows-what kind of errors.
>> Assuming one visits a web page that triggers the use of audio,
> It wasn't visiting a web page that triggered the the dlls to be
> loaded & unloaded. It was displaying a menu, clicking on an item
> in that menu, etc, that caused the load/unload. IOW, any of the
> 7 events listed in MozSounds.cmd.
Then how would audio get played if you did visit a web page that
called for it?
>> would launching and closing Firefox a gazillion times have the
>> same effect on the system that the current version has?
> By "current", I assume you mean 3.5.2 and before. When an app
> closes, the the kernel should decrement a dll's use count by the
> number of loads that app performed. Whether it actually does is
> another matter.
Yes, I meant 3.5.2 and before.
>>> The difference is in scope, not kind. Like I said, both dlls
>>> (mdm & mmio) are loaded just once - only when actually needed,
>>> not when they _might_ be needed - and they're never unloaded.
>> Until the application closes, when the system does it, right?
> Correct.
>>> Note that they're dynamically loaded and not statically linked
>>> solely to enable some hypothetical user who has removed MMOS2
>>> to retain use of the mozilla apps.
>> I'm confused again. When I build a number-crunching program for
>> use by somebody else, I always link statically so that all the
>> necessary library code is included, just in case the somebody
>> else doesn't have the necessary libraries. What you said sounds
>> like just the opposite.
> You're not familiar with how dlls work? The actual code is never
> linked into the app, only references to entry points in the dll.
> By "statically linked", I meant that these references are exposed
> in the Imports list and are resolved at load-time - if the dll or
> specified entry points in it can't be found, the app fails to load.
> By "dynamically linked", I meant that the dll is loaded and its
> entry points are resolved programmatically. If there are errors,
> the app can deal with it and still run successfully - albeit without
> whatever features the dll provides.
Based on Dave Yeo's response, I think we're just using different
terminology.
>>> v3.5.4 is largely a known entity, while v3.7a1pre contains some
>>> significant architectural changes. In addition to my relatively
>>> minor changes to sound, it would be helpful to hear about its
>>> overall performance - in particular, are the windows belonging
>>> to plugins displayed properly?
>> The first thing I noticed is that the double bolding associated
>> with -- what's it called, Workplace Sans font -- isn't occurring
>> anymore. Nice.
> Peter did some work on synthetic emboldening about a month ago.
Hmm, I thought that the font itself had to be changed to avoid
the problem.
>> The next thing I tested is whether Firefox could download a large
>> file. With Firefox 2, I tried to download a file listed as being
>> 4.03 GB in size, but the download manager said it was only 78.8 MB.
>> After inquiring with the owner of the file, I was informed that
>> the file size is 78.8 MB in excess of 4 GB, so apparently we're
>> running into a file size issue with Firefox 2. I told him that
>> I'd give it a try on Firefox 3.7, which I did. Same problem.
> We'll have to look into whether the OS/2 code provides large file
> support. BTW... this is an excellent example of where you'd
> resolve entry points dynamically rather than at load time. Only
> the Warp 4.5 kernel provides this support. If you let the loader
> think you need these entry points, then none of the mozapps would
> run under the 4.0 kernel.
Since I tried the huge file download with the 3.7 pre-alpha, I also
tried it with the latest official release of Firefox for Windows,
Google Chrome for Windows, Safari for Windows, and Internet Explorer
8 for Windows, and they all reported the file as being 78.8 MB in
size, but the owner of the file showed me the directory listing for
the file to confirm its size as being over 4 GB. So nobody seems
to offer support for files larger than 4 GB right now. The
alternative was to download a gzipped version of the file, which
is only one-fifth the size of the original, but unfortunately, the
gzip build for OS/2 dies with a "disk full" error when trying to
uncompress the file (and the disk was most decidedly NOT full).
>> But 3.7 has an additional problem: right-clicking on the link to
>> the file produces the expected pop-up menu. I selected the
>> "Save Link As..." option, which opens the filename dialog, chose
>> my desired destination directory and clicked on OK. But nothing
>> happened. No download occurred. So I left-clicked on the link,
>> clicked on Stop (to avoid having Firefox try to download and
>> display 4 GB of data), and then used Ctrl+S to save the page,
>> which is when the Download Manager appeared and said that the
>> file is only 78.8 MB in size. So the right-click method is
>> currently broken in addition to the file size issue.
> I tried this with several small files and had no problems at all.
> Did you also try this with smaller files? It should come as no
> particular surprise that if one aspect of large file support is
> broken, the other parts may be as well.
Yes, I tried it with small files. Definitely broken for me.
This isn't the first developmental build of Firefox on which
I've noticed the problem either.
By the way, when I tried doing the 4 GB file save by stopping the
display and then using Ctrl+S, it saved only 33.3 MB of the supposed
78.8 MB and then stopped without any sort of complaint. Not sure
if that's a real problem or another artifact of the 4 GB file size
limitation.
>> So far, no problems with my audio.
> You won't really know until you've associated some sound with
> menu popups and menu execute, then endured the noise as long
> as you can. Like I said, this is a stress test :-)
I've noticed some other problems. If I'm displaying a web page
that automatically reloads periodically, such as the box score
from an in-progress baseball game at espn.com, Firefox will
steal the focus every time it reloads the page, which is really
annoying if I'm working in an editor or some similarly interactive
application. Current "official" releases of Firefox don't do that.
Also, if I minimize Firefox and then restore it, sometimes the
page it's on won't repaint itself, leaving my desktop visible
"behind" it. I think the problem is primarily associated with
web pages that reload themselves automatically, but I'd need to
do more testing to be certain of that.
One problem that I'm waiting to see if it will occur with 3.7 is
the one that kills Blackout, an old utility that powers down my
dual-head monitors into standby mode after a period of inactivity.
Every version of Firefox that I've tried to date has eventually
caused this problem, and I know it's Firefox that's to blame,
because if I try to restart Blackout with Firefox still running,
it fails, but if I exit Firefox and restart Blackout, it works.
Blackout tries to spawn a process that actually causes the
power-down after the inactivity period is reached, and when that
fails, a pop-up occurs to note that error. I say "eventually",
because Blackout works just fine with Firefox running initially,
but sooner or later, the spawned process fails, and the only way
to get it up and running is to kill Firefox. Almost as if there
was some sort of memory leak or, perhaps like the audio problem,
a DLL counter that reaches some limit.
tho...@antispam.ham
Yes, I tried it with small files. Definitely broken for me.
Dave Yeo
> The
> alternative was to download a gzipped version of the file, which
> is only one-fifth the size of the original, but unfortunately, the
> gzip build for OS/2 dies with a "disk full" error when trying to
> uncompress the file (and the disk was most decidedly NOT full).
You need a gzip made with klibc for the large file support, Paul Smedley
should have one at smedley.info.
Dave
Dave Yeo
Is it downloading to %MOZILLA_HOME%\downloads?
Also I use an extension called flashgot which passes downloads to wget
(or whatever). Much more robust compared to stock firefox and some of
the ports have large file support.
Dave
Steve
>There was a discussion recently about sound problems after opening
>Firefox. I've created a new test version that contains a fix for
>the issue (I hope) as well as a new feature that should provide a
>good stress-test for the fix. You can get it from:
>
> http://e-vertise.com/warpzilla/firefox-3.7a1pre.zip
Hi,
Gave it a try, even though I don't quite meet the software
requirements stated (fixpack 12?). Anyway I get a window
showing a copy of my desktop. Does this point to the next
upgrade?
Thanks,
Steve N.
tho...@antispam.ham
>> The
>> alternative was to download a gzipped version of the file, which
>> is only one-fifth the size of the original, but unfortunately, the
>> gzip build for OS/2 dies with a "disk full" error when trying to
>> uncompress the file (and the disk was most decidedly NOT full).
> You need a gzip made with klibc for the large file support, Paul Smedley
> should have one at smedley.info.
The gzip web site says that gzip can handle files larger than 4 GB
with a patch, and that the executables at their web site were
already patched. Yet the OS/2 executable didn't work for me on
that large file.
tho...@antispam.ham
>>>> But 3.7 has an additional problem: right-clicking on the link to
>>>> the file produces the expected pop-up menu. I selected the
>>>> "Save Link As..." option, which opens the filename dialog, chose
>>>> my desired destination directory and clicked on OK. But nothing
>>>> happened. No download occurred.
>>> This works fine for me with a build that is very close to Rich's. Did
>>> you try with a file that was less then 2 GB's? I wouldn't be surprised
>>> if there is no large file support.
>> Yes, I tried it with small files. Definitely broken for me.
> Is it downloading to %MOZILLA_HOME%\downloads?
No, as I do not have that environment variable set.
> Also I use an extension called flashgot which passes downloads to wget
> (or whatever). Much more robust compared to stock firefox and some of
> the ports have large file support.
The latest is that I opened a new tab and tried downloading files from
there, and it worked! So I considered the possibility that trying the
large file download may have caused it to break, so I tried the large
file download again, but it still worked, though it only downloaded
about 11 MB of the claimed 78.8 MB (in excess of the 4 GB). Then I
went back to the tab where the problem had occurred, and downloads
started working there as well. So my job now is to find out what
caused it to break in the first place and reproduce it.
But that might be difficult, because my 3.7 installation is now
"broken". I tried one of the ogg-theora videos with 3.7, and a few
of the shorter ones played okay. Then I tried one that is 26 minutes
long, and did some repositioning to replay a segment. When it got to
the end, my system crashed with a Trap d. Now when I try to restart
Firefox 3.7, it attempts to load that same URL, and instantly exits.
I can bring it up in safe-mode, but it won't let me do things that I
usually do with some of the security features disabled. I was able
to get to the page where it let me choose which tabs to not attempt to
recover, but that page isn't coming up without safe-mode, so normal
restart attempts still cause immediate exit.
tho...@antispam.ham
> I thought that it had also solved the problem of FF using enormous amounts
> of CPU time, often in the 70-80% range. This version starts very low (like
> SeaMonkey on similar sites, between 2 and 15%) but after a few minutes CPU
> usage suddenly jumps to 98-100% and stays there, essentially making the
> whole system unusable. If I close FF, either normally or by killing it via
> CAD-popup, the CPU usage stays around 100% for about 2 minutes, while
> there is some intermittent churning of the hard drive, then it finally
> drops to a normal level.
Hmm. That's something I did NOT observe with my test installation. I
left it running overnight with no ill effects.
Pierre Jelenc
I tried again with the Minefield/3.7a1pre version, and the same thing
happens: after a minute or so, the cpu usage climbs rapidly (but not
instantly, it takes at least a minute as well) to near 100% and stays
there, even if I haven even loaded a single page. It then stays at 90-99%
until killed. Unlike with the 3.5xx the cpu usage here drops to 0 rapidly,
within 5 seconds.
Dave Yeo
What happens if you use a new profile? Firefox -ProfileManager will give
you the profile manager, create a new one and test
Dave
Rich Walsh
> I tried again with the Minefield/3.7a1pre version, and the same thing
> happens: after a minute or so, the cpu usage climbs rapidly (but not
> instantly, it takes at least a minute as well) to near 100% and stays
> there, even if I haven even loaded a single page. It then stays at 90-99%
> until killed. Unlike with the 3.5xx the cpu usage here drops to 0 rapidly,
> within 5 seconds.
On the Options->Security page, uncheck "Block reported attack sites"
and "Block reported web forgeries". Then close the browser & restart.
On my system, I'd get 100% CPU usage for 5-20 seconds. After I
disabled these (like I usually do), the problem disappeared.
Pierre Jelenc
>
> What happens if you use a new profile? Firefox -ProfileManager will give
> you the profile manager, create a new one and test
I created a new, empty profile. With both FF 3.5 and 3.7 the result is the
same: every minute or so, whether on a blank page or an HTML one, every
minute or so I get a spike of CPU that climbs to nearly 100% for about 20
second, then comes back down to 1-2%. While the CPU spike is going on,
there is vigorous hard disk activity which ceases when the CPU use goes
down.
With the original profile, which only contains the "NoScript" add-on, 3.5
goes into steady, near 100% CPU use within a minute and stays there no
matter what. With 3.7 I can use the browser for several minutes before the
climb to 100%, and I cannot see any particular trigger: it happens
eventually, regardless of what kind of page I am on in an ordinary site
and --once pegged at 100%-- going to another page (which of course is
rather sluggish) does not cause a drop, even temporarily. HOWEVER, if I
load a plain text file such as robots.txt, the CPU monitor drops back down
to 1% practically instantly and stays there for minutes (at least; I
haven't had the time to test it for very long.)
This happens whether either FF is started directly or via a script that
sets set LIBPATHSTRICT=T and BEGINLIBPATH (there was no other Mozilla app
running during these tests anyway.)
So, clearly NoScript has something to do with it, but on the other hand
it is pretty much indispensible... It's back to SeaMonkey, I guess.
Pierre Jelenc
>
> On the Options->Security page, uncheck "Block reported attack sites"
> and "Block reported web forgeries". Then close the browser & restart.
>
> On my system, I'd get 100% CPU usage for 5-20 seconds. After I
> disabled these (like I usually do), the problem disappeared.
But aren't they good things to have?
Doug Bissett
wrote:
> Rich Walsh <spamyo...@127.0.0.1> writes:
> >
> > On the Options->Security page, uncheck "Block reported attack sites"
> > and "Block reported web forgeries". Then close the browser & restart.
> >
> > On my system, I'd get 100% CPU usage for 5-20 seconds. After I
> > disabled these (like I usually do), the problem disappeared.
>
> But aren't they good things to have?
>
> Pierre
They sound good, but I think there is an equally effective, and less
intrusive, solution. Check out:
> http://www.mvps.org/winhelp2002/hosts.htm
Part way down the page is a link to download HOSTS.ZIP. It is
specicifally for Windows systems, but if you simply replace
\MPTN\ETC\HOSTS with the enclosed HOSTS file, it will block access to
many "bad" web sites. You also need the line:
SET USE_HOSTS_FIRST=1
in CONFIG.SYS.
Be aware, that if you use the HOSTS file for other things, you may
need to add your own changes. The default HOSTS file has only one
line:
127.0.0.1 localhost
which is in the downloaded file, and should be present, unless you
know why it shouldn't be there. The downloadable HOSTS file seems to
be updated about once per month.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
Dave Yeo
> So, clearly NoScript has something to do with it, but on the other hand
> it is pretty much indispensible... It's back to SeaMonkey, I guess.
>
Well it is good to know that it isn't caused by a corrupt profile it is
still strange.
I use noscript in both Firefox and Seamonkey and while I do have a high
cpu usage problem, it doesn't show up until a couple of days of use and
doesn't include disk usage and only happens when scrolling a page (or
switching tabs)
Dave
Pierre Jelenc
> > Rich Walsh <spamyo...@127.0.0.1> writes:
> > >
> > > On the Options->Security page, uncheck "Block reported attack sites"
> > > and "Block reported web forgeries". Then close the browser & restart.
> > >
> > > On my system, I'd get 100% CPU usage for 5-20 seconds. After I
> > > disabled these (like I usually do), the problem disappeared.
This seems to do the trick! I would never have thought of it. Shouldn't it
be set by default in the OS/2 version (assuming it's only us that get hit
by this problem)?
> http://www.mvps.org/winhelp2002/hosts.htm
>
> Part way down the page is a link to download HOSTS.ZIP.
Thanks.
Now that FF looks usable, has there been any breakthrough in synchronizing
bookmarks between it and SeaMonkey? I went through the list of add-ons,
but didn't find anything likely.
Rich Walsh
> Doug Bissett <doug...@telus.net> writes:
> > > Rich Walsh <spamyo...@127.0.0.1> writes:
> > > >
> > > > On the Options->Security page, uncheck "Block reported attack sites"
> > > > and "Block reported web forgeries". Then close the browser & restart.
> > > >
> > > > On my system, I'd get 100% CPU usage for 5-20 seconds. After I
> > > > disabled these (like I usually do), the problem disappeared.
>
> This seems to do the trick! I would never have thought of it. Shouldn't it
> be set by default in the OS/2 version (assuming it's only us that get hit
> by this problem)?
No, this shouldn't be disabled by default because it's certainly a bug that
should be fixed. I can only hope it's not OS/2-only because we already
have all the bugs we can handle, and then some.
However, as long as you're not one of those people who really believes
that their bank has sent them an email requesting them to update their
account info ("just click this link to log in..."), then disabling those
options temporarily is a viable workaround.
tho...@antispam.ham
> Pierre Jelenc writes:
I've observed it now. I had a number crunching program set to idle time
priority that came to a sudden stop, yet the CPU was still at 100 percent
usage. For a while I considered the possibility that the number cruncher
had somehow gone into an infinite loop that avoided any screen output, but
I checked my running processes and found that Firefox was the CPU hog, not
my number cruncher. But after a while, the number cruncher resumed, and
the Firefox CPU usage dropped. After the number cruncher was finished, I
could easily see when Firefox went into high CPU usage mode by watching the
Warpcenter display. At one point, the high usage persisted for a very long
time (many minutes), and Firefox became unresponsive to clicks on the menu
items, but it would open a new tab, for example. Eventually, I clicked on
the "close" icon in the upper right corner, at which point all the mouse
clicks on menu items that had been queued up got executed. and CPU usage
dropped to zero. I went ahead and disabled those Security checks and
restarted Firefox to see if that cures the problem. Curious that I didn't
encounter the problem on my first round of tests. This is now my second
round, and I had to reinstall it, because after the previous system crash,
I never could get Firefox to restart properly. Even a second attempt at
running it in safe-mode wouldn't get past the "disable these things"
stage.