Slow startup after long periods of inactivity (minimized window or other)

RESOLVED FIXED in mozilla1.8beta3



18 years ago
8 years ago


(Reporter: st8, Assigned: brendan)


(4 keywords)

Windows NT
conversion, fixed1.7, helpwanted, perf
Dependency tree / graph
Bug Flags:
blocking1.8b3 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2 rtm] [swapped to disk] [READ COMMENT #206 AND #353 (plus the bugzilla etiquette) before commenting])


(11 attachments, 1 obsolete attachment)



18 years ago
If I minimise the Mozilla browser window on my machine, and leave it for a 
while, - a couple of hours or more - when I come to restor the window to maximal 
size afterwards, the Windows titlebar appears, but it can take 20 seconds or 
more for Mozilla to redraw the rest of the page.

In build 2001041804 but its been around for a while....

I'm running Win NT 4 service pack 5
Sounds like mozilla is being swapped out to disk... how much RAM do you have?

Comment 2

18 years ago
I'm seeing this as well on 2001041920 Win2k with 256 MB of RAM.

Confirming, but I'm not sure if this is really a valid bug - I'm not sure that
this doesn't happen with other applications as well.
Ever confirmed: true

Comment 3

18 years ago
*** Bug 80586 has been marked as a duplicate of this bug. ***

Comment 4

18 years ago
Pasting my comments from bug 80586:

If I leave Moz sitting idle in the background of my desktop for a longish period
(+/- 30 mins) and then raise it, it takes about 30 seconds to become responsive
again. Mad disk activity (swap) before it becomes usable again.

Is this perhaps just Win2K's dodgy VM system ? 
I would say yes since the OS should handle bringing apps back to life after the
memory has been swapped off somewhere else, but all other apps under windows are
basically immediately responsive after sitting idle for a long time.
Is Moz's footprint to big to have state kept long enough ?

Apps like outlook have just as big a footprint, yet are almost immediately
responsive on raising after long idle times.

I recall talking to someone about this.  The problem may be that Mozilla uses 
lots of files (gif, css, js, etc) instead of being a single binary.  All these 
(especially the images) get swapped out of memory much more aggressively than 
binaries do, apparently.  And take a while to bring back.

Comment 6

18 years ago
Actually, windows 2000 aggressively swaps out libraries too. 

The problem isn't that they get swapped out, it's that mozilla needs too many 
of them before it can resume functioning.

I have no idea to whom this bug could be assigned...
Keywords: arch, hang, helpwanted, perf

Comment 7

18 years ago
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
QA Contact: sairuh → claudius
nav triage: moving to m1.0 since not sure if this happens for lots of users. 
Keywords: nsbeta1+
Priority: -- → P4
Target Milestone: --- → mozilla1.0

Comment 9

17 years ago
don't think I'll get to this by mozilla1.0, marking mozilla1.2
Target Milestone: mozilla1.0 → mozilla1.2
*** Bug 109301 has been marked as a duplicate of this bug. ***
*** Bug 97376 has been marked as a duplicate of this bug. ***
*** Bug 112689 has been marked as a duplicate of this bug. ***
*** Bug 115515 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
I have read other comments. There could be some Windows 2k optimization that
helps the matter, like not swapping dlls etc. Does anyone else think that
fiddling with w2k can help?

Comment 15

17 years ago
*** Bug 98241 has been marked as a duplicate of this bug. ***


17 years ago
Blocks: 74634

Comment 16

17 years ago
This is getting duped a lot.  Updating summary to be more self explanatory.
No longer blocks: 74634
Summary: maximise the brower window, takes a long time for browser to display → slow startup after long periods of inactivity (minimized window)


17 years ago
Blocks: 74634

Comment 17

17 years ago
It happens on NT as well

if we can't find this optimisation, I don;t think anyone else will.  Maybe since
each mozilla needs so many files, is it possible to join them to a single file,
with an index,  and only use that ?  Might be a good idea to stop fragmenting
peoples file systems as well.

This is annoying though especially since it takes away some of what quick launch
gives us.  Please fix it :)  it stops me running mozilla regularly.

-> default assignee
Assignee: pchen → trudelle
QA Contact: claudius → sairuh
Target Milestone: mozilla1.2 → ---

Comment 19

17 years ago
Hi all.  My first time posting on Bugzilla, so be gentle.   I'm not much of a
programmer, but I've been doing some testing on this problem.    I collected a
ton of performance counters on several different programs that had all been
sitting idle for 30 minutes: Acrobat Reader 5, Netscape 4.79, Mozilla 0.9.7,
Star Office 6, and Winword 97.

To begin with, I timed how long each program took to become responsive after
this time period.   Mozilla was by far the slowest at around 45 seconds.  
Acroread was next at about 25 seconds.

At first I thought it was page faults, but Acroread generated a mind boggling
1943 page faults when re-activated, compared to only 480 for Mozilla.

Then I thought it might be # of handles and DLLS opened that had also been paged
out.   However, ProcessExplorer tells me that StarOffice had 809 handles and 74
non-system DLLs opened.  Mozilla had 62 non-system DLLs and only 176 handles.

I checked a number of other things, such as # of threads and CPU %, none of
which was illuminating.   

Then I discovered that when Mozilla was re-activated, it's working set
(allocated bytes, I believe this means) went from 2.4MB to 22MB!   Conversely,
the next biggest jump was winword which went from 2.1MB to 6.5MB.

I don't know if this is particularily enlightening, but it seems to me that
Mozilla is all of a sudden trying to grab a lot of memory when it wakes up.   If
you real programmers want me to continue testing, I'll be happy to do so.

For the record, I'm using a 600Mhz Pentium III with 128MB RAM running Windows
2000 Sp2.

dp, what do you think of the data in comment 19?
Thanks Turin.

This is my guess: The 2.4 MB that we see when mozilla is *inactive* is the
amount that is truely used in memory (all usage - swapped out pages). Thus when
reactivated, all the pages that are required get swapped back in -> 22MB.

So the jump isn't the interesting part. The fact that 22MB is used is
interesting. But we know mozilla does take that much memory.

The slower reactivation could be painting happening slowly + time required to
swap in 20 MB (22 - 2.2 MB)

Comment 22

17 years ago
45 seconds on a P3/600?  That doesn't sound normal.  Did you mean 4-5 seconds?
(Which is still longer than I've ever seen on my P3/700) Could be thrashing. How
much memory is available when you do this?

Comment 23

17 years ago
4-5 seconds is really interesting. It could be good to know Your windows
configuration. Or can anyone find out if the difference is caused by using XP
instead 2000: Jan

Comment 24

17 years ago
Peter... I did in fact mean fourty-five seconds!   Upon further tests that was a
high number, but it never gets below twenty-five seconds.

It is true that this only happens when Mozilla is paged out.  I also understand
about working sets now.  However, more tests have shown me something interesting..  

I loaded my system down with a bunch of applications that all have about the
same memory footprint when they are first loaded, including Netscape 6.0,
Outlook 97, IE5.5, StarOffice 6.0, and Mozilla 0.9.7.   I minimized them all,
then played around with Photoshop to ensure that they all got paged out.   When
they were all down to about 2-5MB working sets, I started maximizing them and
seeing how long it took for them to become responsive (by which I mean that I
could click on a menu and the menu would open right away).

Mozilla was definately the slowest and I noticed that when it was maximized, it
did not become responsive until it's working set had grown to almost its
original size; 19MB in this case.    Even Netscape 6 which started with 27MB and
refused to give it up for the longest time, started responding promptly when it
had 15MB.  StarOffice needed 10, IE needed about 9, & Outlook only wanted 6.8MB.

IANA Real Programmer, but this seems to suggest to me that Mozilla cannot
function properly unless all of its various DLLs and other resources are loaded
into memory, whereas other software is not so particular about having all of its
resources in memory.

I hope this helps in some way.  I have access to an XP Pro system, so I'll try
this under XP as well and let you know the results.

Comment 25

17 years ago
Not sure who should get this. Cathleen, could you suggest someone?
Swapping in 22MB and potentially swapping out 22 MB wouldn't cost 45secs. I am
guessing the delay is more involved with the painting.

Comment 27

17 years ago
If it helps more, this is exactly what I experience:

When I click on the minimized Mozilla icon on the task bar, the outline of the
window and the title bar come up immediately.   After about ten seconds, the
menu bars are drawn.  After twelve-fifteen seconds the rest of the window is
drawn.  If I initiate any action around this time, such as clicking on a menu or
hitting a button, it takes about five seconds to respond.   Only after a minimum
of 25 seconds have passed will the application be completely responsive.

Comment 28

17 years ago
DP: What part of 25 seconds do you think painting would take?  I'm guessing a
small fraction of 1.
Peter: A small fraction is what painting *should* take. The time of 20 secs to
redraw after reactivation is time-for-swapping-in-memory + time-taken-by-redraw

We think either of these shouldn't take that much time. So we got to account for
which of the two is taking more time and why ? My guess is more on the

Comment 30

17 years ago
I can easily notice the slowness, after doing a build on my machine.  Bring up a
minimized window is noticibly slow on a 1 GHz machine...  Maybe someone can try
to create the slowness situation this way.

Comment 31

17 years ago
I still have no idea who should get this.
QA Contact: sairuh → jrgm

Comment 32

17 years ago
I've seen the same thing happen when Mozilla sits idle in the System tray.  Its
making Quick Launch useless to me.  I'm sure its a coming to life problem.   It
happens quite common on my PII 333MHz with 192Mb memory

Comment 33

17 years ago
->hewitt for triage
Assignee: trudelle → hewitt

Comment 34

17 years ago
I confirm this bug. Windows XP, 1Ghz Celeron, 512MB RAM (!!!). 
Memory usage normally never exceeds 200-300 MB.
Mozilla "wakes up" very slow anyway with lots of disk activity.
Tried to change "Large system cache" - no change noticed.
Don't blame MS this time, please ;-))

Comment 35

17 years ago
Are people still seeing this on current builds under NT/Win2k/XP?  Blake made
some changes that should help this.  Also, is this only happening with QuickLaunch?

Comment 36

17 years ago
I see this sometimes.  I don't think it has to do with QL but our painting/view
manager code.  Frequently the chrome will show up first and then it takes time
(during which the app is hung) for the content area to fill in.

Comment 37

17 years ago
I see the following: window's frames appear quickly but content is repainted
very slowly, especially in Mozilla Mail window.

Comment 38

17 years ago
I still see this on win2k, 256MB RAM. Outline comes up fast, but content takes
ages to get filled in. Its not as bad as it used to be, but still painful -
around 10-15 seconds to come properly back to life

Comment 39

17 years ago
cc varga

Comment 40

17 years ago
I guess, window outline comes up real fast because it is painted by native
window manager. For app menu we need XUL, for content area HTML, ...
so all this stuff need to be swapped in.

Comment 41

17 years ago
nominating for MachV, ->morse
Assignee: hewitt → morse
Keywords: nsbeta1

Comment 42

17 years ago
nsbeta1+ per Nav triage team, Nav2, ->1.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nav2]
Target Milestone: --- → mozilla1.0

Comment 43

17 years ago
*** Bug 134084 has been marked as a duplicate of this bug. ***

Comment 44

17 years ago
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!

Comment 45

17 years ago
Setting OS to All because it happens in all windows versions.

I really think this bug is INVALID/WONTFIX because it's caused by the bad VM
design of Windows. Windows swaps out all inactive applications even when there's
no pressing need.
OS: Windows NT → All

Comment 46

17 years ago
i don't think this sould be marked INVALID/WONTFIX because even Corel Draw swaps
in faster, and even after mozilla is swapped in it stays unresponsible/unuseable
for a  few moments, while corel draw for example is ready to work but mozilla
takes a signoficant time longer to be fully work-ready.

i personaly don't think this is the only fault of the bad VM of windows, i think
there is more than just that.

Comment 47

17 years ago
killing os all. all should be used when multiple os families experience a bug, 
this is limited to win32 so all is inappropriate. I see no references to w9x so 
Windows NT is the oldest version of the win32 family where this problem happens 
which means it's the os we should report..
OS: All → Windows NT

Comment 48

17 years ago
sorry, it affects win98se too. i'm using Windows 98SE and i have this problem
too. so all windows versions should be correct.

Pentium3, 650 MHz, 192 MB RAM, Windows 98SE

Comment 49

17 years ago
This is *very* annoying bug, because bringing Moz from traybar takes longer than
launching Moz 100% from death ;). Usually it takes some 40-60, and that is very
long. This is very blocker for 1.0 release, and almost completely makes "Turbo"
mode unusable.

Athlon 600MHz
256MB ram
Windows XP

Comment 50

17 years ago
converting nav2->adt2
Whiteboard: [nav2] → [adt2]

Comment 51

17 years ago
Like in #49 I have to say this is really annoying. It takes up to 60s wake up so
if you're working with other programs, it's almost every time that Mozilla got
paged out and is somewhere in Nirvana. Quickstart is useless, the normal startup
time (which is long already) is faster. I remember this not being serious in
earlier builds let's say before 0.9.7 but I'm not too sure about that.
Some people I made use Mozilla already went back to IE just because of this :(

Win XP
Build ID 2002031104

Comment 52

17 years ago
It's Windows VM that is to blame making "Quick startup" very slow. Try disabling
paging file (No paging file at all). Everything works excellent! 
I've got 512MB on my Windows XP Pro machine and don't use pagefile.sys at all.
It proves that VM managagement swaps out most of Mozilla code/resources...

Comment 53

17 years ago
Not to beat a dead horse, but, I must concur with previous posts. Mozilla is 
taking way too long to restore. This can not be the OS (entirely) because this 
is the only program that I have this problem with. Lotus Notes is one of the 
biggest hoags that I have seen and it restores in seconds (< 5sec at worst 
case). This is the main reason that I have not switched to Mozilla exclusively. 
IE just runs better right now. I hope that this can be resolved since I find 
Mozilla a much better feature rich platform then IE.

Comment 54

17 years ago
I think it's way too easy to just blame windows again. Mozilla is the only
program that takes THAT long to wake up. I work with Corel DRAW, OpenOffice and
Photoshop at the same time and all three of them come to live considerably
faster than Mozilla alone.
Sorry for just confirming this bug but I think this is very important cause most
of Mozilla-Users are Win-Users who are far away from having enough ram to work
without VM. And, of course, it's so much easier to switch back or stay with IE
if you don't care about Microsofts behaviour.
Just wondering if things are a little better on today's builds : Apr 09 2002

Last night I disabled resident set reduction and I am thinking it might have an
effect on this modulo high memory pressure from other apps. Let me know.

Comment 56

17 years ago
I'm not quite sure if it helped. I took two times. One starting up from
minimized state, one completely from quicklaunch up to menus and stuff reacting

minimized   25s (2002031104) - 6s  (2002040903)
quicklaunch 40s (2002031104) - 60s (2002040903)

Hopefully this was the right build with the named changes implemented since
there were many nighly builds and I just took the latest.

Comment 57

17 years ago
I don't know whether this is important, but Mozilla does take longer than other
OS X apps to become active once it's been swapped out of memory. (I record
around ten seconds on my G4 450, but OS X in general is slow on a G4 450, so I
didn't really notice till now)

Comment 58

17 years ago
There were a couple of comments about this happening while using QuickLaunch,
but is everyone seeing it *only* in QuickLaunch (i.e., it doesn't happen with QL
Blocks: 108795
I'm not a guru, but I want to try to provide an explanation.
I guess that the problem here is the excesive modularity of Mozilla (xpcom for
everything). This causes that in order to do minimal tasks, the processor is
jumping allover the place executing differente support components, like for
getting StringBundles, or accessing a file on disk, etc. I don't know how can
this be solved. Perhaps controlling the link process in order to keep critical
sections together. Sorry if what I've just said is all crap, or too obvious.. :/
I'm no expert on this.

Comment 60

17 years ago
Could the swapping to disk just be (optionally) disabled?

Comment 61

17 years ago
Let me share my 2 cents worth.

Other apps' interfaces are drawm by Windows itself. In Mozilla, only
the titlebar is drawn by Windows, the rest is drawn by Mozilla itself.

After long periods of inactivity, Windows resurrects Mozilla quickly,
as evidenced by the immediate showing of the titlebar. But since most
of Mozilla is swapped to disk, it takes time for Mozilla to redraw

Other apps are unresponsive also, but their GUI is shown immediately
because they do not have to draw their own interface.

Comment 62

17 years ago
this is a pretty serious bug - worse on mozilla than other large applications. 
also, though, for mozilla's original goal of being "small & fast", it's awful
large!  it takes up more ram than lotus notes or my java swing applications,
both known for being huge.

this bug will likely turn many potential users away (and back to IE) if it isn't
fixed :(

Comment 63

17 years ago
Does the fix for bug 125100 affect this?


17 years ago
Keywords: mozilla1.0
Yes. Fix for bug 125100 could do anything from not affect this to help this.
Wont cause any worse behaviour. My guess is it might help it in most cases.

Comment 65

17 years ago
I think a lot of this is due to the Mark/Sweep GC mechanism. Once most of
Mozilla has swapped out, a GC cycle will touch most of that memory and require
it to be read back in before much of anything can be done.

Comment 66

17 years ago
Some benchmarks:

After doing some rendering & other memory consuming things WinXP taskmanager
shows Mozilla mem usage 1304K. ("Quicklaunch" only active)

Startup time: 
Titlebar appears: ~15 seconds
Rest appears: ~20 seconds.

For comparison, Nutscape 4.77 startup time is ~10 seconds.

While RC1 starup times is lots faster than 0.9.9's 40sec, but i'd still like to
see it pushed at 10 sec...or faster.

Athlon 600MHz
258MB Ram
WinXP Pro


17 years ago
Whiteboard: [adt2] → [adt2 rtm]

Comment 67

17 years ago
I just thought I'd note that Mozilla is the only app I've used to exhibit this
behavior under both Win2k, WinXP, and MacOS X. And this includes development
environments, graphics packages and other enormous programs on the same memory
usage scale as Mozilla. I have a 1 Ghz Athlong with WinXP, and 733 Mhz with
Win2k, and a 500 Mhz with MacOS X. (All with 256 megs of ram.) I don't have
quicklaunch enabled on any of them.

Leaving Mozilla inactive for anything longer than a few minutes and it takes
between 30 and 60 seconds for it to become responsive again, on all three
platforms. (Oddly, Mac OS X is the fastest, even on the slower computer. But not
by much.)

This is a serious problem, and I've had to mostly stop using Mozilla at work,
because I've grown tired of explaining to co-workers looking over my shoulder
that I'm waiting for Mozilla to wake up, again.

Comment 68

17 years ago
My system:
1 GHz Athlon C, 512 MB RAM, WinXP

The slow maximize bug can occur after just a few seconds:
With or without QL activated, Mozillas RAM allocation drops from about 20+ MB to
3.5 MB after minimizing all Mozilla windows. Copy large files (400 MB+) and
restore a minimized Mozilla window during the copy process takes some minutes
longer and it takes about 30 seconds up to 3 minutes (!!!) to see the restored
window and work with it. This is a nice way to see this issue instantaneous.

Killing the process and restarting Mozilla is way faster than restoring a window
(like others here experienced). With 1.0rc1 there is a noticeable speedup but
restoring a window shouldn't take longer than killing the application and
restarting it.

Can't Mozilla be forced to keep everything in memory when minimized?

Comment 69

17 years ago
Then you'll get people complaing that Mozilla is slowing down other applications
when minimized because its not release that memory.

Comment 70

17 years ago
I am unable to duplicate this.  Tell me what's wrong with my testcase:
- computer is P3-850, 256MB ram, WinNT, recently defragged
- Mozilla build 2002-05-01-branch, installed browser-only, Quicklaunch active
- I load NT's taskmgr.exe and set it to display Mem Usage *and* VM Size
- on initial load, mozilla.exe uses 19MB/13MB of memory, respectively
- I load multiple pages, get the mem usage up to ~40M, then minimize all
- mozilla.exe goes to 18MB/25MB
- copying large files, loading other apps, waiting 15min, etc. 
  all fail to reduce the Mem Usage stat (in ram) below ~18MB
  Mozilla is immediately responsive when I unminimize any window
- I close some of the browser windows and it goes to 2MB/22MB
- I copy a bunch more files, but the File Cache never goes above 50MB
- *NOW* Mozilla has to reload from cache but it still takes less than 5 sec.

Are you sure y'all aren't just suffering from fragmented swapfiles?  I'll keep
testing it, and try to get more than "just" 22MB swapped to disk...

Comment 71

17 years ago
@ #69:
Isn't that what quickstart should be? holding everything in memory so it's
faster accessed? what else is that function good for?

@ #70:
It could be XP specific. XP uses all free memory as a disk cache. Mozilla frees
up some memory -> Windows XP grabs it for disk caching purposes while copying
large files -> Mozilla needs a lot of time to restore its windows. I don't know
if 2k uses the same technique. Could someone check that?

Comment 72

17 years ago
You are correct, Windows 2000 and XP both more aggressively cache disk accesses
than previous version of Windows, but I don't think that's a big issue.

Keeping Mozilla resident would solve the problem for Mozilla. That risks being
labeled a bad neighbor. By not relinquishing the working set when Mozilla is not
in use will cause an overall degradation of performance, since this will
effectively reduce the size of the disk cache. So we'd be improving Mozilla at
the expense of other applications. If I have Mozilla in the background doing
nothing I don't want it degrading my overall system performance uneccessary.

I think what other posters have mentioned about fragmented swap files would be
good for people to investigate first. If your swap file is able to grow, and
your disk is fragmented this can have a drastic performance hit. If I run an
application on my system that allocates large amounts of memory, I can easily
get Mozilla swapped pretty much completely to disk. On my system it can take up
to 10 to 15 seconds to get Mozilla responsive after it has been completely
swapped out. If I do something that causes a garbage collection cycle this time
can be doubled. This is on 733mhz laptop with 384megs of RAM, with I'm sure a
rather slow hard drive. I have defragged my drive and my swap file is fixed. If
you're system it taking longer then you may need to defrag or check into the
transfer rates of your hard drive. You?ll need to reduce or eliminate your swap
file, defrag, then set the size again.

What shaver is working on for bug 66381 is probably the best solution, this
should reduce the amount of pages we touch during a GC cycle.
*** Bug 142095 has been marked as a duplicate of this bug. ***

Comment 74

17 years ago
#71 Also happens on NT as well

Do we know for certain thats what the problem is ??  If its not so hard to put
together a build which doesn't release memory when the window is minimised or
Moz is being launched from QL, then maybe that would be a good idea and it could
be tested in the way described in #68.  

Comment 75

17 years ago
It seems to me that 1.0rc1 made Mozilla "longer" responsible. I also think
Mozilla is more agressively trying to be responsible in the first place, but
takes longer to open menus and stuff once seeming to be finished with paging in.
So the look&feel should be faster for the average user.
Once Mozilla is paged out completely it seems to me it even takes even longer to
wake up than 0.9.9. 3min like in #68 is quite normal. One should wonder about
the sense of quicklaunch then...
Since I am working with memory-consuming apps all the time and need to look up
things in the web/ check mail in between I'm almost always waiting for ages for
Mozilla to wake up. I think this is a very serious structural Problem of Mozilla
drawing itself and I don't think it can be solved soon without keeping mozilla
resident in memory which would of course be very unelegant. I never thought so
but I'll probably be leaving Mozilla as browser since I'm just tired of staring
at the screen and then (cause I was to impatient) seeing 4 Mozilla windows
popping up at once, trying to use one of them and close the others and then wait
again for ages for these tasks to complete. My disk is on heavy pressure all
this time.
I can't reproduce this behaviour at all on linux or osx like in #67 though on
osx (G3-600) the performance is sluggish overall but that's another story...
I dunno that much about bugzilla but please, the ones who are in charge: This
bug is definitely very serious and could be the one and only reason to drive
users away from mozilla so please adress this to high priority.

Comment 76

17 years ago
It was the first anniversary of this bug last week! :)

Seriously though, this is how long it has been around.  Its not a new thing, and
it certainly not improved at all in any build I've used since (the milestone ones).

Please see this fixed before the release

Comment 77

17 years ago
I know y'all are probably tired of hearing from me, since I don't have a
problem!  Still, I thought it would help to give a little more description of
what I see:

- when I minimize Mozilla, the NT Task Manager shows it aggressively swap to
disk (i.e. "VM Size").  So Mozilla is being a "good" app by not fighting to stay
in RAM.
- after a moment, the code slowly starts swapping back into RAM (i.e., "Mem
Usage").  This probably happens because I have enough unused memory; my "Commit
Charge" is typically ~160MB, and I have 256MB installed.

Can the W2K and XP users try to duplicate this, please?  You need to open Task
Manager and change the default Processes display so that it includes "VM Size".

Also, is there someplace in the builds where one can specify the memory
"priority"?  If so, then maybe these settings needed to be adjusted so that the
important parts of Mozilla will 'try harder' to stay memory-resident.

Comment 78

17 years ago
On Win2k, when the problem occurs, the memory is:

Mem Usage, VM Size (sizes are approx):


On clicking the toolbar icon to bring focus, it goes to:


On actually trying to browse (e.g. click refresh) it goes to:


So.. unless the VMSize isn't reduced as programs are swapped in, it's new memory
being allocated/program code being loaded that causes the disk churn/slow response.

Comment 79

17 years ago
The VM isn't affected by whats in or out of the paging file. The VM size is the
amount of memory committed to a process whether it currently resides in physical
RAM or is store in a swap file. This would be expected to remain somewhat stable
when restoring an application.

The churn is caused because you're paging in almost 20 megs of data by the time
you're done with refresh. And the time required to page this in, is dependent on
the throughput of your harddrive and controller, and how fragmentted your paging
file is, whether it has to swap out other data to accomodate the requests. If
the OS has to reduce other working sets, it may end up writing out 20 megs of
data as well as reading it. On my system it takes about 30 seconds to restore
Mozilla when it's been swapped out and can recover the memory from
non-workingset sources.

Comment 80

17 years ago
David B.,  I don't think your description of "VM Size" is correct.  If it
represented the size of the entire working-set, then it would always be equal-to
or larger than the "Mem Usage" stat, but it isn't (on NT at least).  So, I still
think it represents the amount of virtual-memory in-use by the process.  This
makes it very interesting to note that the "Mem Usage" stat grows without "VM
Size" being reduced.  

Perhaps Mozilla is releasing memory needed for on-screen display, then
re-requesting it when unminimized?

Also, when inspecting (normal) apps like Outlook, they don't surrender nearly as
much code to VM as Mozilla.  For instance, when I minimize Outlook it maintains
9MB in RAM, my financial calculator program maintains it full 5MB (w/o
surrending anything to VM), while Mozilla maintains just 2MB (the other David's
comment #78 was just 100k!).  

Comment 81

17 years ago
I've just been playing..

When I load the system, eventually the Mem Usage figure goes down.  The VM Size
doesn't appear to go up though but remains stable.

If you also view the Page Faults count, when you click mozilla to bring it to
focus, you get lots of page faults.  I thought this was a count of how the VM
system had to page data in and out of RAM/Swapfile.  If so then this backs up #79.

Interestingly, I've been running IE6 in parallel (iexplore), and that had a size of 


which reduced to


On clicking, it does the same and the Mem Usage goes back to


So... I guess it does similar, but is just swaps back in much faster than
Mozilla due to smaller memory footprint.

My question... why is mozilla so large?  I thought it was supposed to be a
'lightweight' browser, for use on anything from embedded devices upwards.  Yet
IE appears to have a much lower memory usage.  I guess integrating
mail/news/composer/irc etc has it's penalties.
David: It's not that Mozilla is particularly large, but IE 'cheats', since much
of it is integrated into the OS.

Comment 83

17 years ago
Re: Comment 80: the definition I gave is the one given in the in Task Managers
Help, but looking at it it is incomplete. Task Manager has been notorious for
such things and I should have looked elsewhere for the definition. VM Size is
actually the same as private bytes. "Private Bytes is the current number of
bytes this process has allocated that cannot be shared with other processes".
That's why VM Size can be less than Working Set.

Re: Comment 82: Agreed, it does share DLL's and probably other things. However
IE's process does use about 1/3 less virtual address space than Mozilla, which
would include anything that is shared. Now virtual address space is tricky, as
it doesn't necessarily equate to memory, and it depends a lot on how it's being

Comment 84

17 years ago
Is this related to bug 639 ?

Comment 85

17 years ago
I'm seeing this annoying bug also.  Very sloppy.
Among others, I'm using these apps:
Autocad 2000
Corel Draw
PaintShop Pro
Macromedia Dreamweaver,
Netscape 4.7+
win2000, PIII 512 megs ram
I'm seeing the same 15-20 freeze when un-minimizing Moz RC1 after 15-20 
minutes.  This is NOT a Windows 2000's problem. People fall too easily for this 
excuse.  When Moz is the ONLY program doing this, you CAN'T blame the OS.  All 
of these other programs un-minimize almost instantaniously.  Moz churns the 
hard drive so bad and long, that it's scary.  Defragged system makes no 
difference.  Moz is the problem here.
This and the funky text wrapping bug (83378) are probably the two biggest black 
eyes on Mozilla and should be addressed before 1.0.  It seems these bugs are 
the result of *not* coding for windows first (with 95% market share), then 
porting to the other, more obscure OS's, but rather coding for the obsure OS's, 
and then *trying* to get it to behave on windows.  Regardless of the facts, 
that's the impression.
*** Bug 145591 has been marked as a duplicate of this bug. ***

Comment 87

17 years ago
Come on guys! Isnt this obvious: it is the very apparent bugs in the Mozilla 
memory manager/garbage collector. Although reducing the working set (after 
minimize) to the minimum is the *right thing*, but I don't think that swapping 
out the life critical data (like UI parts) is the sane idea. I would rather 
prefer to keep all the skin stuff to be kept in memory.
My (probably pretty dumb) question is: Is it possible to split the cache items 
to those which could be easily swapped out to disk cache (like current opened 
pages) and to those which should be stay in memory (like browser window skin 
As a short-term solution I would rather check the impact of using the standard
(not garbage collected) malloc() API just for allocating data for all the UI 
stuff, and would see the result.

Comment 88

17 years ago
One of the first problems in isolating the cause of this problem is to come up 
with a reproducible test case.  Waiting around for 20 hours is not acceptable.

So I wrote the following program which allocates and touches all of virtual 
memory, forcing all background programs to be swapped out.  My machine has 512MB 
of virtual memory so that is how much memory my program touches (actually it 
touches about 10% less than that because the program crashed when it tried to 
touch all the memory).  You might have to adjust this number for your particular 

The way to use this is as follows.
1. Bring up an application and then minimize it
2. Run the program shown below
3. Maximize the minimized application and time how long it takes

I tried this with Mozilla, Netscape 4, and IE.  Mozilla took about 15 seconds 
whereas Netscape 4 and IE took about two seconds.


#include <stdio.h>
#include <stdlib.h>

main(int argc, char *argv[])
  char*  memory;
  memory = (char*)malloc(500000000); // allocate all of memory
  int i, j, k;
  for (i=0; i<29; i++) {
    for (j=0; j<4096; j++) {
      for (k=0; k<4096; k++) {
        memory[16777216*i + 4096*j +k] = ' ';
  return 0;

Comment 89

17 years ago
Correction to my last posting:

   the program crashed when it tried to touch all the memory

The reason it crashed was because my math was wrong.  I allocated 5,000,000 
bytes and then tried to touch memory beyond that.  If I wanted to touch all 
512MB in my machine I should have used a larger allocation.

Furthermore, even though my machine has 512MB, I noticed that page swapping 
started to occur when I got to about 90% of that value (after the 27th time 
around the outer loop the print statements came out significantly slower).  
Obviously not all of the 512MB is available to my application.

Comment 90

17 years ago
Created attachment 84444 [details]
Application to hog memory

I created this a while back to play around in stress testing memory. It's a
Windows only executable, though. You can allocate blocks of memory, and then
have it touch all that memory on demand. They used to have something like this
in the Windows resource kit or SDK, but I couldn't find it.

It was interesting as it didn't behave exactly like I thought it would. On
allocation the working set climbs but then falls and then expands and shrinks
several times. It does easily produce the behavior in Mozilla this bug

Also it's interesting to have two instances of this app running and battling
each other.

Also, I see two lags. One is when the window is first brought up. The second is
when you go do something non-trivial (view another page, new window, etc.) and
looks like GC kicks in.

Comment 91

17 years ago
I just experimented with Bradley's memhog program, and it behaves essentially 
the same as the one I posted above.

I just want to clarify what I think is some confusion in the postings above.  
There are several different time points:

1. Native window outline and blue title bar appear (native win32 code)
2. Mozilla's chrome area appears (XML code)
3. Website content area appears (HTML code)
4. Menu buttons become responsive (C++, javascript code)

Several of the comments refer to 1 occuring very quickly and then a long delay 
before 2 and 3 occur (bug description, comment 27, comment 40).  Comment 36 on 
the other hand confused me since I thought it was saying that 1 and 2 occur 
quickly and then a long delay before 3.  On re-reading that comment, I realize 
it was ambiguous.  I'm posting this just so others don't get confused.

What I personally am seeing (and what I believe the others are saying as well) 
is that 1 occurs quickly, long delay, then 2 and 3 occur (sometimes a noticable 
but small delay between them) and then another long delay before 4 occurs.

Comment 92

17 years ago
re:, your sequence is
exactly what i'm experiencing as well.

Comment 93

17 years ago
In response to #91, I would say that you cannot give a single 'the delay is
here' type reply.  I have seen delays at different points.  For me, the delay is
more typically when trying to browser again rather than just displaying the
current window/contents when flipping back to the process.  But, after not using
it for a longer time, the delay is as you say.

I guess the answer is really 'it depends what windows has swapped out'.

Comment 94

17 years ago
Here are some numbers that dp and I obtained by instrumenting a trunk build from 
May 24.  We performed the following experiment:

1. Bring up browser
2. minimize window
3. run the memory-touching program of comment 88
4. maximize the window

Durint the maximize phase, there is a dispatch of a SYSCOMMAND message (code 
112 that was taking all the time (about 12 seconds).  So we instrumented to a 
finer granularity to see what was happening during the SYSCOMMAND.  The 
results were as follows:

> Actions that occurs when a SYSCOMMAND (112) message is received.  This
> was obtained by instrumenting nsWindow::ProcessMessage.  The curly
> braces have been added to show where nesting occurs.  Specifically they
> are used as follows:
>    {a a} around call to OnResize(rect) in WM_WINDOWPOSCHANGED
>    {1 1} around first call to DispatchFocus in WM_SETFOCUS
>    {2 2} around second call to DispatchFocus in WM_SETFOCUS 
> D:s(112)        <<< start of dispatching of SYSCOMMAND (112)
>     a} > 1349MS <
>  a} 1485MS
> -WM_SETFOCUS  {1 >< 1}{2
>    -WM_SETFOCUS  {1 ><>< 1}8387MS  <<< here's the offender
>  2}10043MS
>    -WM_SETFOCUS  {1  1}{2
>     2}41MS
>  1}218MS
> d : 12335ms  <<< end of dispatching of 112, time taken is 12.3 secs

Note that the bulk of the time is spent in the WM_SETFOCUS case in the 
nsWindow::ProcessMessage method of nsWindow.cpp.  This is occuring in a nested 
call to SETFOCUS, and the bulk of the time is spent of the following call in the 
nested instance:

     result = DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus);

Comment 95

17 years ago
The above results were with a debug build.  To better zero in on the problem, I 
decided to try the same experiment with an optimized build.  This time the delay 
was less (as was to be expected) -- about six seconds.  Unfortunately the delay 
was not as reproducible as with the debug build.  That is, simply running the 
memory-touching program did not get back to the state of getting the six-second 
delay again.  I occasionally got the delay, but for the most part the 
window came up almost instantaneously.  Exiting and reentering the browser 
didn't help either.  This makes it very hard to localize on the problem.

Comment 96

17 years ago
OK, I can reproducibly get the delay with the optimized build if I reboot the 
machine after each test.  Makes it very cumbersome to run repeated tests of 

Here are the timing numbers for the optimized build.  Slightly faster than for 
the debug build, but the offending call is in the same place.


     a} 842MS
 a} 982MS
-WM_SETFOCUS  {1  1}{2
   -WM_SETFOCUS  {1  1}4800MS  <<< big offender
   -WM_SETFOCUS  {1  1}{2

d : 7391ms

Comment 97

17 years ago
cc'ing danm and bryner since I had already discussed these timing numbers with 
them in private e-mail and they had some comments on it.

Comment 98

17 years ago
Note that the maximum amount of time on an optimized build is only 7 seconds, 
and that time occurs only on the first maximize following a reboot.  All other 
maximizes are almost instanteous.  I'm running on a 450MHz machine.  So this 
doesn't appear to be a problem.

Is any still seeing really long delays on an optimized build?  If not, this bug 
might be a non-issue.

Comment 99

17 years ago
Mail & News Window and one browser with three tabs in it, both minimized:

Memory usage: 4 500K
VM size:      21 588K

Maximize time without any heavy memory usage program: instant (0,5sec)

Now, i launch Tribes2 (good online game) and play it for a while. After exiting
mozilla memory usage is about:

Mem: 8000k
VM: 21552k

But launch time is now ~18,7 seconds (finished swapping, and browser is usable),
title bar appears in ~2 seconds. With some even more memory hungry programs, 18
sec is fast, i have seen it go near 40sec. So, how do i get that to your 
heads that it is an *issue* and it is not because of fragmented HD. Same effect
is avery PC where i have tried it, mostly on win XP but also in NT 4.0
(serv.pack 6).

Athlon 600mhz
258MB ram
WinXP & WinME

Duron 800mhz
516MB ram

Athlon TB 1000mhz
256MB ram

Celeron 300mhz(?)
211mb ram
NT 4.0 (serv.pack 6)

Comment 100

17 years ago
For comparison sake, here is the timing for the case in which the window 
maximizes nearly instantaneously.


    a} 9MS
 a} 18MS
-WM_SETFOCUS  {1  1}{2
   -WM_SETFOCUS  {1  1}16MS
   -WM_SETFOCUS  {1  1}{2

d : 385ms

Comment 101

17 years ago
Just in case there was doubt in anyones mind as to where in the SETFOCUS code 
the time is being spent, I've instrumented further to show that it is in the 
calls to DispatchFocus.  In the following data, the number following }1 shows 
the time spent in the first call to DispatchFocus, and followig }2 shows the 
time in the second call to DispatchFocus.


    a} 813MS
 a} 883MS
-WM_SETFOCUS  {1  1}108 {2
   -WM_SETFOCUS  {1  1}3974 3976MS   <<< the offender
 2}4894 5004MS
   -WM_SETFOCUS  {1  1}0 {2
    2}9 11MS
 1}434 436MS

d : 6646ms


Here's the code to SetFocus with the two calls to DispatchFocus clearly shown:

        if(!gIsDestroyingAny) { 
          result = DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus); 
          if(gJustGotActivate) {
            gJustGotActivate = PR_FALSE;
            result = DispatchFocus(NS_ACTIVATE, isMozWindowTakingFocus);
I ran Quantify on this and it seems that we're spending most of the time from
DispatchFocus inside nsXULCommandDispatcher::UpdateCommands, executing 2 js
event listeners.  What's interesting to note here is that commands are being
updated because the focus controller is not suppressed.  However, on Linux, the
focus controller is suppressed, so we don't do UpdateCommands.

saari, danm, or anyone -- should the focus controller be suppressed here so that
we don't update commands?  I'm not familiar with the event ordering on a window
restore, but perhaps something is causing us to unsuppress early.

Comment 103

17 years ago
Thanks Brian.

Can someone tell me what the call to

   result = DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus);

in SETFOCUS does?  Since this is the offender, and the large amount of time fir 
this call occurs only when the SETFOCUS code is executed with gJustGotActivate 
false, I experimented and put the the above line inside the if(gJustGotActivate) 
statement.  That reduced the total time significantly.

But without understanding what this call is doing, I don't know what dire 
consequences moving this line of code would have.
That line dispatches a NS_GOTFOCUS event, which causes onfocus handlers to fire
and our internal focus state to get updated.  The "activate" event is fired when
a toplevel window receives focus that did not previously have focus.  So, if I
remember correctly, the entire sequence goes something like this:

- receive WM_ACTIVATE
- receive WM_SETFOCUS on the toplevel window (WebShellWindow)
- fire NS_GOTFOCUS on the WebShellWindow, which suppresses the focus controller
- fire NS_ACTIVATE, which restores focus memory.  This will cause us to:
 - focus the widget that receives focus from focus memory, triggering another
  - Unsuppress the focus controller

So, in theory, the focus controller remains suppressed the entire time, so I'm a
bit mystified as to why we're updating commands.
Steve, right after restore before we got the SYSCOMMAND did we get a few (order
of 5) activates and deactivates ?

Anyway, my general feeling was we are doing way more than what we need to for
min, restore.

Comment 106

17 years ago
Yes.  After clicking on the icon on the status bar to maximize the window, we 
got the following activity prior to the SYSCOMMAND.

D:a(c0ac)d : 1ms
I'll take this.  I'm testing a patch that should help this quite a bit.
Assignee: morse → bryner
Ok, explanation and patch forthcoming.

When the app is minimized on win32, we actually null out the focused window on
the focus controller.  This causes its own set of problems which are covered in
bug 95704.  It's not clear whether the patch in that bug will actually fix this
issue though.  Anyway, the order of the null checks in
nsWebShellWindow::HandleEvent means that we don't suppress the focus controller
if the there is no saved focused window.  That causes us to do a _lot_ more work
than we need to, including a deactivate and updating commands twice.

My patch simply causes us to suppress focus whether there's a focused window on
the FC or not.  It will be unsupressed when we get an NS_ACTIVATE event
following the NS_GOTFOCUS.  In my test, it made us about 3x faster at restoring
the window after memory had been exhausted.

So, this probably needs tested on multiple platforms, especially with cases of
minimizing and restoring, activating/deactivating, and changing focus within a

Comment 110

17 years ago
I applied brian's patch and have obtained some very strange results.  The time 
reported by the printf's in my program (see below) is now indicating 2.566 
seconds which is a definite improvement over the what we had before which was 
about 7 seconds.  That's the good news.  The bad news is that my stopwatch time 
didn't agree at all.  It indicated about 9 seconds.  Previously my stopwatch 
time was in the same ballpark as the time reported on the printf.

I tried this three times and got the same sort of result each time.  I'm 
hard-pressed to explain how the stopwatch time and the printf time could differ 
by so much.

Furthermore, in viewing the printf's as they came by, I saw a very long delay 
after the first -WM_NCCALCSIZE occurred.  And of course that delay is not 
reflected in any of the times reported by the printfs.

Another change is that now there is are two distinct delays in bringing up the 
window.  One is after the window frame appears, as was the case before.  But a 
second one is occuring after the browser chrome is displayed but before the 
browser content window is filled in.  That second delay was not as pronounced 

    a} 768MS
 a} 894MS
-WM_SETFOCUS  {1  1}133 {2
   -WM_SETFOCUS  {1  1}98 99MS
 2}1063 1198MS
-WM_SETFOCUS  {1  1}0 {2
   -WM_SETFOCUS  {1  1}0 1MS
 2}31 32MS
d : 2566ms
Ok, let me reprofile this with my patch applied and see if anything new shows up.

Comment 112

17 years ago
Here's some more information.  The reason that my printf statements no longer 
show the bulk of the delay is because significant delay is now occuring outside 
the regions that I was looking at.  Specifically, the posts that I've included 
above are for the timing within the dispatch of a system command 112.  But if I 
look further down in my output, I now see a long delay (which I don't think ws 
there before) in a WM_PAINT following the dispatching of the 112.

In reading the output below, note that "D" means the beginning of a dispatch and 
"d" is the end of the dispatch.  The number appearing after the "d" is the total 
time for that dispatch.

    a} 620MS
 a} 717MS
-WM_SETFOCUS  {1  1}163 {2
   -WM_SETFOCUS  {1  1}112 114MS
 2}793 958MS
-WM_SETFOCUS  {1  1}0 {2
   -WM_SETFOCUS  {1  1}0 2MS
 2}42 44MS
d : 2086ms

D:a(c130)d : 1ms

d : 27ms

d : 1721ms

D:a(c130)d : 1ms

d : 49ms

d : 10ms

d : 10ms

d : 245ms

d : 630ms
Can anyone who is experiencing this problem regularly try applying this patch
and see if it helps at all?

Unfortuantely, the profile after applying the patch simply shows a lot of time
spent painting, which is exactly what is expected.  It simply takes awhile
because of the sheer quantity of code that we have to bring in from swap to
repaint the window.
*** Bug 150479 has been marked as a duplicate of this bug. ***

Comment 115

17 years ago
I regularly have this problem at work and will give the patch a try tomorrow.
Tim, had a chance to try the patch yet?

Comment 117

17 years ago
Bleh, Unfortunately, I found out today I did not have all the MSVC components I
needed to build mozilla(though I can build abiword just fine). I'm not sure how
soon I'll be able to reinstall MSVC to get what I'm missing(it was an ATL header
file, I'm suprised not to have it). Can anyone place a patched build somewhere I
could download? I would be more than happy to test it. 
I've posted an experimental 1.0 branch build with this patch at:

(For anyone reading bugmail vigilantly, it may take 15 minutes or so from now
for the build to appear on the server).
Ok, i'll try it after work, later today. Any chance getting this to 1.01?

Comment 120

17 years ago
My initial feeling is that the patch does improve the restore time I'll try to
get some hard numbers later. Neither of the memory hog apps seemed to work for
me so I wrote my own. One thing I notice is that a restore after the manual
memory hogging does not take as long overall as a restore from when mozilla has
been minimized for half a day. BTW this is on a Windows XP machine w/ 128 MB of
RAM and I never have this problem on my XP machine at home which has 512 MB of
RAM. (I know, that's probably obvious) Also I emailed the author of comment #19
since he is not on the CC list.
Thanks for the email, Tim.   I have added myself to the cc list now.  This bug
has certainly generated some interest since 1.0!   I thought it might.

For the record, my current Windows system is a P4 1.6Ghz w/ 128MB RAM running
W2K Sp2.  Mozilla 1.0 still takes about 25 seconds to wake up after being paged out.

Unfortunately, I cannot seem to download the patched binary.   Attempts to
connect to give me connection closed by remote host.   Can you
email the binary to me?  Otherwise, I'll try to connect again later.
If this patch helps, we need to know fairly soon if it is going to make MachV. 
If not, I'm afraid this will need to be pushed out until we can figure out some
way to require less code to be swapped in in order to paint the window.
Well, I've been trying out the patch.   Preliminary tests do show that it
greatly speeds up the wake up time for Mozilla.   However, every time I try to
get into Mail now, I get a c0000005 access violation error in mozilla.exe.   I
even tried creating a new profile, but same problem.

Can anyone else confirm this?
I'm not seeing that problem on my machine.  What is your mail configuration? 
Does it crash as soon as the mail window comes up, or when you try to log in?

Comment 126

17 years ago
I have the mail crash problem as well with the experimental binary. As soon as I
click the envelope -> Boom. In fact, 1.1 alpha's mail does not work properly
with me either, so I had gone back to 1.0.

Comment 127

17 years ago
Okay. FWIW, I left experimental build running with so-called quickstart enabled
for half a day while I was playing games etc. Then I activated it and it came up
in about 5-10 seconds, instead of the 30-45sec it took before. Big improvement,
yes. Still room for more. For whatever reason mailnews does not croak on me
anymore. No idea why. 

Comment 128

17 years ago
Although I have not had a chance to perform a "stopwatch-test" I can definitly
say the problem has not been as bad since I've been running the patched version.
It went from  "major nuisance" to "minor annoyance" on my system at work.

Comment 129

17 years ago
Let's not make subjective guesses here.  It's very easy to get an actual number 
and compare it with and without the patch.

First of all, forget about turbo.  It has nothing to do with this bug.

What you want to do is start up the browser normally (no turbo running) and then 
minimize the window.  Next you need to play around with memory hogs a little 
(see next paragraph).  Then you maximize the window and use a stopwatch to time 
how long it takes for the page to appear.  Also you might want to keep timing to 
see how long until you can get a menu to drop down (although that's a little 
harder to time).

The hard part is the memory hogs.  I've found neither my version (comment 88) or 
bradley's (comment 90) are very repeatable.  That is, they will always work the 
first time, but they might have no effect after that.  And you'll know if it 
doesn't work because the window will appear instantly when you go to maximize 
it.  So, in the worst case, reboot your machine after each test.  But I found 
it's usually not necessary to do a reboot -- bringing up a few heavy programs 
and then closing them (N4 for example) usually suffice.

I did exactly as described above (see comment 110) and observed an increase in 
stopwatch time for the window to be maximized.  Please try the same test and let 
us know whether or not your observations agree with mine.  Thanks.

Comment 130

17 years ago
Not everyone has a C-compiler installed. I have the custom build, I can test it
against the nightly build with same date. It breaks my mail, so it's kinda
inconvenient for any prolonged testing..

Comment 131

17 years ago
I spent half'n'hour playing with the memhog. It's rather misleading to have it
as ".cgi", since it's really a zip-file. In any case, what you have to do is to
try'n'hog a little bit less than your physical ram and keep of touching the
allocated block. You can monitor it with the task manager, after a few cycles
memhog will have everything available. On my 256MB box, you can allocate
225x1000000 .. 230x1000000 will result in a much smaller ram footprint as
windows will swap hog right out.

Ok, the result: Inconclusive. I had ~10 second delay coming up to an active menu
with both patched and nonpatched version. This was after making sure memhog had
grabbed all available ram and freeing it afterwards. 

The REAL problem for me is that when I use(d) quikstart, starting mozilla would
take very, very, very, very, very long time to start. Think 1 minute and up.
Getting rid of quikstart got me back to about 10 seconds. Quikstart equals
having mozilla minimized all day, no? The difference in the synthetic test and
memhogging is that EDA tools really do put the boot in to get their RAM, unlike
our piglet.
On the trunk, saari's fix for bug 82534 should make this patch irrelevant.
Pushing this out.  I don't think we're going to get anywhere with this soon, and
I don't have time for it right now.
Target Milestone: mozilla1.0 → mozilla1.2beta

Comment 134

17 years ago
I get this real bad.  My computer at work is quite slow (PII) and I always have
alot of windows open at once and change between them often.  I find this quite a
sudden change from Moz being able to return from minimised instantly at one
point in  time, and taking 30 seconds (and then being slow and unresponsive for
30 seconds more)

Does anyone have a build with some timing code in that I can play with?  I'm not
familiar wuth the code and I don't think I'll get the time to make the changes
myself, but I'm quite keen to see this fixed so that I can use Mozilla again. 
If someone can give me a build containing the stats you already have I'm sure I
have a good chance of finding out more about it

Comment 135

17 years ago
It seems to me that 1.1 beta suffers from this problem more seriously than previous build(s). OTOH, this porblem is much more severe on the workstation I have at work than with my home PC, even if the former is quite a bit more powerful and they both run W2k with SP3 applied. I just now had to wait for 40 seconds for mozilla come up and become responsive after being minimized. System resources show approximately 64MB of unallocated physical RAM  and no other apps are open. However, a while back I was working with word etc, so it is quite possible mozilla was swapped out.

In any case, I think it's completely unreasonable to tag 30+ second reactivation time as "ok" since starting mozilla from scratch takes a lot less time. I usually leave the mailnews app open to get a notification of any new mail and the response time is as bad either just opening a the mailnews or firing up browser window. If I actually get an email notification, mozilla comes up just like that when I click on the envelope. Apparently it does whatever it does prior to giving me the email notification. 

Comment 136

17 years ago
Yuck! Is the missing linewrap a bug with bugzilla or mozilla? 

Comment 137

17 years ago
*** Bug 163046 has been marked as a duplicate of this bug. ***

Comment 138

17 years ago
I'm glad to find this bug and I'm surprised to it still drag on for almnost 1 
1/2 years.  I use Win2000 and I didn't like this bug becuase it slow down 
everything.  It seem to be improving as it approach Moz 1.0 but didn't do so 
well as it approach Moz 1.1 beta.  For the sake of everything, here's this wild 

Make the browser appearance show up first fast and quick.  Then make the 
functioning of the features like menu bar, buttons, history list, etc. to work 
2nd.  Remember it only take human being a second or two to response.  Then 
somehow bring up the most recent to the front while still bringing up 
everything at the bottom of the pile back up and running.  Wouldn't it make 
sense that way??

P.S. The OS should not be set to WinNT since it also affect most of the 
Windows.  Should it be change to ALL??

Comment 139

17 years ago
'All' implies all OSes, not just Windows.  Its set as 'Windows NT' because
that's the earliest Windows version it affects.  I suppose it could be set to
'Windows 95', but the point is rather moot.

Comment 140

17 years ago
Cool!  How about a new creation in the OS scrollbar.  Let's say "Windows 
(ALL)".  That way, it represent about all Windows.  Yes, We know that Win95 and 
Win98 use similar architecture.  The same for WinNT and Win2000.  WinXP is the 
combination of (Win95 & Win98) and (WinNT & Win2000).  It doesn't meant they 
all share the same architecture type.  So, a penny for my thought!  It would be 
cool to see that "Windows (All)" in the OS scrollbar as a new addition.
Scott: This isn't really the place to request a change in the OS options ;).
However, if you would like to do so, you can file a new bug in the product
"" under one of the "Bugzilla ..." components.

Comment 142

17 years ago
i'll second the notion that this "seems" worse recently that it had been.  it
felt to me like the trend was getting better, and even up to the 20020814 1.1
nightly build, i think, was better that it had been a few months ago.  i had
actually quit conciously noticing it.  however, 20020818 seems significantly
worse than all those other recent builds.  i.e. it's back in-my-face obvious
again :-(


17 years ago
Blocks: 163993

Comment 143

17 years ago
I did a little bit of a experiment.  See comment #134, I use Pentium II with 
128 MB RAM.  The way Virtual Memory work, it worked pretty well the way it is 
suppose to be.  There is no sign of Resource Hog.  See comment #113, Brian 
Ryner stand correct about the time being spend on painting the whole screen.  
The frame outline and the blue bar at the very top showed up instantly except 
the painting of the rest.  I use the MS-Outlook and Visual SlickEdit.  I played 
around in clicking on those in the task bar.  

I noticed the response time of the painting is a bit slow the first time.  Once 
fully painted, I minimize it and quickly bring it back up.  The painting did 
not seem to be redrawn and it act as if it was already there.  Did this 
experiment on a couple of other applications and got the same result.  

So, I test it on Mozilla and noticed a very noticeable difference with the 
repeating action of minimizing and un-minimizing Mozilla with the click of a 
mouse in the taskbar.  The problem lie with the draw/paint starting time.  It 
just did nothing for almost 1 second then immediately start drawing/painting.

You can tell when you see the window bar at the very top (above the menu 
selection), it already shown up and the rest below of it isn't.  You will need 
a superman's eye to see the speeding bullet, so you'll have to look at it 
carefully.  All you need to do is to see the window bar and the color below it 
at the same time to see it.  Do the clicking on the Mozilla in the taskbar to 
minimize it and un-minimize it repeatly, let your recognization of the images 
and shape to sink in and you'll see what I meant.  

This will be a very useful tool in debugging the delay in draw/paint starting 
time, allowing you write the patch almost on the fly.  No need to wait 30 
minutes for Mozilla to become idle while it is already minimized.  I urgently 
suggest that you use this method because timing is more efficient.  Just don't 
bother to stare at the effect for 10 minutes or your eye will popped out!  All 
you need to do is to use common sense and find out why did the draw/paint 
starting time stayed idle for almost a second (with the minimize & vice versa 
stimulately) before it start painting.

I have the confident that once this problem is fixed then you'll find a faster 
response time when un-minimizing Mozilla after 30 minutes of idle time and find 
the draw/paint starting time to be a little bit quicker.  Worry about the 
draw/paint completion time later.  Hopefully, you all will adopt this method 
for starter.  Like why did it wait to start painting?

Do you agree with that?  What about you, Brian Ryner?

Comment 144

17 years ago
When this happens, Mozilla is slower at coming back up than it is when it is
first launched.  The big memory footprint probably has a lot to do with this.

So a thought for a test build is to clear the memory cache whenever you minimize.

Comment 145

17 years ago
I'm adding a comment because I can't believe this bug isn't a huge priority.
With 3.4% (and shrinking) total user base - see article snippet from Salon,
below - how can releases of this product continue to ship with bugs that
render Mozilla unusable?  I would love to use any reasonable product in
place of Microsoft software, but I can't wait a minute or more for Mozilla
to respond each time I need to access the web.

One last drink for old times.  I'm sadly switching back to IE.

Sept. 10, 2002  |  On Aug. 28, WebSideStory, a firm that keeps statistics on the
software that people use online, released some numbers confirming what most Web
surfers who think about such things already know: Almost nobody uses the
Netscape Navigator Web browser. WebSideStory reported that Netscape, the company
many people credit with sparking the Internet revolution, is now forlorn in the
world it helped create, claiming only 3.4 percent of the world's Web users.

That's a stunning decline from just a year ago, when Netscape had a 13 percent
share -- and especially from the company's heights of the mid-1990s, when
virtually everyone used its browser. But now, 96 percent of the people online
use Microsoft's Internet Explorer, and it's likely that Netscape will lose even
more ground in the future, according to WebSideStory.

"The browser war," said one of the firm's executives in its press release, "is
in fact a massacre." 
Since I switched to Mozilla 1.1 and activated QuickLaunch, the problem seems to
be minimized. Does it only apppear with no QuickLaunch option used, or is it
resolved in Mozzilla 1.1?
Do not underestimate this problem, it's not have been voted 27 times for
nothing. This is very annoying bug because it's totally unpredictable for those
who actually uses their computer something else than browsing. This is very key
may of my friends choosing between Mozilla and ...rival... browsers. For me,
restoring browser takes 1-40 seconds, from taskbar or from systray and it's
*really* making me nuts when trying to do something fast. Btw, its not about my
HD is fragmented as some of you tried to point.

There is patch already for this and i really hope that it will land to 1.2.

Tested on:
Duron 900, 256MB.
WinME, WinXP, WinNT 4.0 sp6

Comment 148

17 years ago
If you're talking about the 6th of July patch, it's not quite a clear-cut solution. Coders talk about milliseconds, where the real problem is having to wait upwards of 30 seconds on a high-end box. I get hit with this one bad at work, where I use some big footprint apps daily. Simplest workaround is to never leave mozilla open, minimized or not. Interestingly, when I have forgotten mail open and I *know* it'll take forever to restore mozilla, trying to kill the process takes just as long.

For what it's worth, I haven't paid attention to the problem lately, so 1.1 is not as bad as some builds. Maybe.

Comment 149

17 years ago
This bug used to drive me up the wall but since I re-installed W2k on a new hard
drive the problem has gone away.  The new hard drive is NOT phyiscally faster
than the old one.

This raises questions to me:

- Is it just that more recent versions of mozilla are better (now using >1.1)
- I had degragmented the old hard disk, but perhaps the swap drive or registry
or something was still fragmented or something
- Maybe it's just a windows thing - I've noticed an FDISK once a year really
helps anyway
- Maybe my tolerence level has gone up and I don't notice the odd delays now and

I should mention that the problem hasn't completely gone away - occasionally
there are still several second pauses on a reload, but not the 30 second ones I
used to get.

Comment 150

17 years ago
From comment 146, the quick launch reserved some spaces in the RAM.  It was 
design to make the Mozilla fire up more quickly when Moz isn't running.  I'm 
not aware of this feature being used for minimizing and un-minizing, I don't 
think there is one for this.
Wow.  Some people don't get that:

1) Bugzilla exists to help solve bugs, not bash programmers.
2) Whining is not going to get a bug fixed.
3) If you value speed of waking over security and features, by all means go
ahead and return to IE.

Personally, I solved this problem for myself rather nicely.  I wiped w2k and
installed Mandrake.

Comment 152

17 years ago
Can anyone confirm seeing this problem with 1.1 release? I used to have it real bad at work (w2k) with 0.9x-1.0. Now it seems to just have gone away..

I saw a mention in release notes that the quicklaunch now reloads mozilla when the last window has been closed. Sounds like a workaround, but if it works for now.

Comment 153

17 years ago
Nope, I still got this in 1.1. Just installed 1.2a so will report back in a few
days if it's any better.

Comment 154

17 years ago
As stated before, this is a serious bug. Today I had a discussion about the
prefered browser with two of my collegues. And although they would choose
another browser over IE it wouldn't be Mozilla right now.

The main reason is the huge swap-in delay Mozilla has in Windows (2000), if this
is solved I'm sure I can convince one of them to switch and almost sure the
other would switch too. [And actually I would be happy too :-)]

Comment 155

17 years ago
I doubt that anyone disagrees that resolving this issue is of importance to the
long-term success of Mozilla.  I have heard many anecdotes of sloth-like
restores from a minimized state within my own organization and among friends.  I
even experience the issue periodically.  While it has not significantly
diminished my enjoyment in using Mozilla, it is high atop the lists of peoples'
pet peeves; it seems especially so among those who would be less likely to use
Bugzilla because they feel no particular need to help Mozilla become better than
it is today.

That said, I would agree with any of the programmers who have said that fixing
this is not going to be easy.  I am not sure if I share the optimism that asks,
"is it fixed in the latest build?"  Without knowing for certain, it sure seems
that fixing this sort of thing would involve a significant undertaking.  If that
is true, then it won't be fixed without some follow-up fanfare.

All I can add is to reiterate that low-memory is just an easy way to replicate
the problem and not really the definitive cause.  Every time I have experienced
the issue, my machine was not in a low-memory situation.  It's just that Windows
2000's super-aggressive paging algorithm decided to page out Mozilla merely
because it was minimized, even though I may have 500Mb of memory free.  Silly

Another application that exhibits the same behavior--and is actually much worse
about it--is the Eclipse development environment.  That bad-boy takes its sweet
time to restore from an overnight minimized state.

Comment 156

17 years ago
Nobody was ever fired for blaming microsoft. Even if W2k/XP memory management was dodgy, how come majority of apps can deal with it? Why is it much faster to fire up Mozilla instead of restoring it? Why is there no disk churning or other system slowdown when mozilla takes forever to come up?

My personal quess would be that a small wait somewhere in the code is getting called n times with right conditions. Could it be possible to produce a test build which would log breakdown of the time spent bringing up moz? With timestamps, maybe? That way whoever is hit with this problem this week could actually do something productive about it..

Comment 157

17 years ago
I see some people still don't read all of hte comments carefully and went on to 
post comments or jumping the gun.  Here's a saying, "Don't count the chick 
before the egg hatch"!

See Comment #19, Comment #96 and Comment #112.  Comment #112 is as result of 
the patch from 6/6/02 but on comment #132, the bugfix make this patch 
irrevelant.  Based on Comment #19 and from what everyone have been saying, the 
window frame showed up instantly but the paint redraw haven't fired up for a 
while.  So, what make the WM_ERASEBKGND, WM_PAINT, WM_NCPAINT taking it's 
time?  Should be something we should look into.
Unfortunately, I'm wrapped up in other work and probably won't be able to look
at this anytime soon.  This bug should probably get a new owner.  Anyone willing
to step up?

Comment 159

17 years ago
FWIW I think we can conclude from all the memory stress testing that the problem is NOT a simple Win32 performance issue. At least I had mozilla coming up way way too fast after playing with the memhog applet. I made sure all the non-core physical memory was committed by memhog and restored mozilla window. Furthermore, I had the expected disk churning while restoring mozilla after hogging.
*** Bug 166337 has been marked as a duplicate of this bug. ***

Comment 161

16 years ago
I just wanted to add an observation.  If my rough judgment of time doesn't
deceive me, Phoenix (0.3) seems to be even worse than Mozilla 1.1 (on my Win2K)
*** Bug 163930 has been marked as a duplicate of this bug. ***
I think that it's related to mozilla working set being too high
Maybe a MOZ_COVERAGE build coud help here
MOZ_COVERAGE is supposed to minimize page faults by putting code used
during a given test scenario (startup, maximizing, minimizing, etc...) in adjacent  
pages. This is a 2 pass process, first collect the data then make a final build
with the collected data.
I think that it could be usefull when Mozilla gets maximized after a long period
of inactivity.
Unfortunately I don't know if MOZ_COVERAGE is still available with new GNU make
build system.

Comment 164

16 years ago
*** Bug 182306 has been marked as a duplicate of this bug. ***

Comment 165

16 years ago
The bug is still present in Mozilla 1.2 under XP. About 20-30 seconds restore
time, and this is the only application where the problem occurs. I watched CPU
and memory usage on my Athlon 1800+ (256 MB) during the slow redraw, but they
stay way low (no significant difference to normal idle operation), so this is
not the reason for the bad performance.

Comment 166

16 years ago
Something that can really kill performance is two disk accesses at the same
time. It's hard to believe that simply swapping could kill performance so much,
but maybe it's something else, like trying to read from the cache at the same
time as Mozilla is read in from the swap file. That could cause really bad I/O
performance. It would be interesting if this is seen by anyone who has the swap
file on a seperate disk (completely or at least seperate from the cache disk). I
should try to see what's happening with sysinternal's filemon, but I have
trouble reproducing it. The 'hang' only happens when I not expect it.
One interesting thing sicking and I (mostly sicking) ran into the other day is 
that when you unminimize the Mozilla window on Windows we actually reflow (as 
in, nsHTMLReflowState::Init gets called, which means that a reflow is happening 
somewhere).  On Linux, unminimizing does not involve a reflow.  Is this because 
on Windows unminimizing involves a resize operation and thus triggers a resize 

Comment 168

16 years ago
When you minimize on Windows you'll get a WM_MOVE and then a WM_SIZE message
sent to you. Is that what you are referring to?
iirc (sicking, correctly if I'm wrong) when we _minimize_ we don't reflow.  
When we _unminimize_ we reflow.... It may be worth seeing whether we can 
eliminate that reflow and if so how it affects this bug.

Comment 170

16 years ago
Re comment 166 - I have my swap file on a separate physical disk (on Win2K), and
I still get this bug.
Yes, we didn't seem to reflow on minimize but on we do on restore. Maybe we have
some code somewhere that suspends reflows/repaints when in minimized mode which
is why only the unminimize causes a reflow.

Either way it might be a good idea to try to not cause any reflows between the
minimize and the unminimize so that on onminimize we only have to repaint.

Comment 172

16 years ago
as long as you leave the reflows in the queue and process them when you
unmimimize, otherwise dynamic content can get unhappy

Comment 173

16 years ago
I don't know whether I can shed any sort of light on the issue (and after
reading through most of the 170+ comments, I doubt that I can), however one of
the things that I DID notice between my work computer and a coworkers:

we have almost identical machines (Windows NT4 with SP6), same harddrives, same
everything (he has a little bit less harddrive space left than I do), BUT I am
using a built in video card (that uses shared memory), and he has a separate
(some nVidia card) video card with it's own memory.  I see the problem, he doesn't.

I don't know if it's related to a onboard video card memory swapping competing
with normal memory swapping or something.

I ALSO see a problem (probably unrelated) when I click the minimize button.  My
whole terminal locks up for about 5-10 seconds (nothing works outside of mouse
movement) after I click the minimize button.  It's almost like the "window
manager" is frozen (except for the mouse).  If I have a Task Manager showing, it
halts while the whole computer is 'frozen' then unhalts itself (which a super
quick spike in CPU useage at the tail end of the halt that almost immediatly
goes back to normal).

Comment 174

16 years ago
*** Bug 185460 has been marked as a duplicate of this bug. ***

Comment 175

16 years ago
This is not a hang. It's a performance issue. I'm not sure that the "arch"
keyword is appropriate, either.
Keywords: hang, mozilla1.0 → mozilla1.4

Comment 176

16 years ago
Can anyone explain what the 'arch' is???  Short for architecture??  That's what 
it look like.  The term 'performance' is the apppropriate term as long as it is 
not the term 'stability'.

Comment 177

16 years ago
I have noticed this more on my computer recently, with 1.1b happen quite swiftly

I have installed Visual C++ and using lots of other resource heavy apps.  Since
then I've produced this problem regularly while VC++ etc are running.  The specs
of this machine are:  750 Duron, 128MB, Win2K SP2 recent install, Creative
GeForce 4 MMX 440 video card.  There is no improvment in performance over the
orginal machine I reported this on. (333MHz Windows NT etc).  It is possible I
can find a set of steps to reproduce this

Comment 178

16 years ago
FWIW, this is worse in 1.2b than 1.1 .. With XP1700+ and 512MB. 
st8 and Olli: Your builds are rather old. Please try a more recent build:

(as always, be sure to delete your old Mozilla directory before installing the
new one)
*** Bug 191774 has been marked as a duplicate of this bug. ***

Comment 181

16 years ago
*** Bug 196055 has been marked as a duplicate of this bug. ***

Comment 182

16 years ago
as i point out in my dup Bug# 196055 comments...

running Debug->Leak Detector->Dump Memory Leaks seems to restore normal

wouldn't a simple solution be to just call this routine, or whatever garbage
collector is preferred, every 5-10 min???  yea, it's an ugly hack, but if it

for the record, this bug still exists in 1.3b (Mozilla/5.0 (Windows; U; Windows
NT 5.0; en-US; rv:1.3b) Gecko/20030207)...

Comment 183

16 years ago
*** Bug 194959 has been marked as a duplicate of this bug. ***

Comment 184

16 years ago
In bug 194959, which has been duped against this bug - it was pointed out that
the problems only happened when using specific video card / drivers - Nvidia
Geforce4 MX 420 (Driver

Performance problems ended using an earlier version of the Nvidia driver (

The problems were also solved by going to and downloading their
recommended latest drivers (as opposed to those endorsed by MicroSoft). Running
with driver version does not have any delay in maximising windows.

If it s a true dup, perhaps updating video drivers would benefit others-
although the behaviour in bug 194959 occured all the time - not just after long
periods of inactivity.
I can see this problem with an Nvidia card and the latest drivers.

I have always seen this problem with all versions of Mozilla since 0.6 something
both with my old K6-2-300Mhz/ATI card and my newer AthlonXP1700+/Nvidia.

That's the reason why I never leave Mozilla open during the night (PC is on
24h/24h), it can take up to a minute to "wake up" on the morning.
this is not limited to nvidia cards since i'm defenetly seing this and i don't
have nvidia

Comment 187

16 years ago
Isn't it possible to analyze or debug the scripts' effect in the Mozilla's 
files and compare it to varieties of video cards to see if there is a pattern 
as to what cause the problem with the delay in unminimizing the browser 

It wouldn't hurt to give it a try because something might be there where we 
least expect it.  I don't know where to start from there.

Comment 188

16 years ago
It seems to me that the video card issue is something else entirely, since it
happens immediately instead of after long periods of inactivity, and this issue
is seen with all video cards.  I don't think that bug should actually be duped
to this one.


16 years ago
Flags: blocking1.4a?
Keywords: arch

Comment 189

16 years ago
since no one seems to have tracked down the source of this bad boy yet, it may
be helpful to note that i cannot seem to reproduce the problem with only a
single window open (ie: prob appears w/ multi tabs, not when all tabs are closed
save one)...

can anyone else confirm this?
I've seen this without any tabs whatsoever, too. (I never use tabs). Also, I
believe that when this bug was filed, Mozilla had no tabs.

Comment 191

16 years ago
I too can reproduce this with no tabs.

Comment 192

16 years ago
Running a Norton Corporate AntiVirus scan with Mozilla minimized seems to be a
repeatable way to cause the problem on my machine.


16 years ago
Flags: blocking1.4a? → blocking1.4a-

Comment 193

16 years ago
These comments apply to a Win2k machine with 392Meg of RAM

Does Windows have some sort of memory allocation call that allows an application
to specifiy it's degree of "unwillingness" to be swapped to disk when minimized?
If I open a .PDF document in a tab and then minimize Mozilla, the Adobe Acrobat
Plugin seems to stick around in RAM hanging onto 30Meg while Mozilla will shrink
down to a 1.2Meg or so when minimized.

Comment 194

16 years ago
Then you'll get a bunch of other people complaining about how Mozilla slows down
other applications when it's not in use.

Comment 195

16 years ago
Is there a middle ground here? Could the strategy change based on available
physical memory?

Comment 196

16 years ago
c'mon people.  What memory is paged out and what it not, is decided by the
operating system kernel.  The only way an app can affect that is by changing
which parts of memory it "touches" (reads/writes), or by calling a memlock
routing on whichever OS mozilla is running on (but in unix,you need root access
for that, and that's not an option).

This bug should depend on the bug for large memory footprint, and that's it.

Comment 197

16 years ago
Mozilla memory footprint is neglible in 512MB machine. And it sure should not
take one minute/sixty+ seconds to fire things up after long time of not being
accessed. No other app I have suffers from such slow restore time. 

Comment 198

16 years ago
Using the latest Mozilla, Pheonix, and Thunderbird on WinXP, PIII 750 512 megs 
ram on a well defragged system.  ALL of these programs have one heck of a time 
coming back from being minimized for several minutes.  If you happen to be 
doing some video editing, they NEVER really come back.  Much quicker to right-
click the taskbar button, kill them and start over.  This isn't getting better 
at all.  By comparison, Opera 7+ comes through the same tests with flying 

Note that Opera and Moz/Pheonix/Thunderbird all have about the same memory foot 
print.  They all swap out to disk down to about 5 megs or so, and all use about 
the same mem foot print while running (17 to 20 megs). So it's NOT that they 
have a huge memory foot print.

So, why has Opera figured out how to function on an NT class machine and Moz 

I've got to say that this alone is keeping a lot of people from using 
Moz/Pheonix/Thunderbird as their main browser/mail.  N7 is, of course, just as 
bad.  I can expect this from Thunderbird, being new and all, but 
Pheonix/Firebird behaves just a badly as Mozilla 1.4a.  My work has over 200 
win2000 machines and will not use any of the Mozilla products because of this.

The killer is, Moz is a great product otherwise.


16 years ago
Flags: blocking1.4b?
Flags: blocking1.4?
Target Milestone: mozilla1.2beta → ---

Comment 199

16 years ago
I have seen from other bug reports that you cannot request a bug blocking if
there is no patch(es) or if no one is currently working on it.  Just letting you

Comment 200

16 years ago
Adding vote.  And asking for a priority change to "Major".

Comment 201

16 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326

There are reports from OSX, and now Linux requesting OS->ALL

Re: Comment #5
bz, Is there anything we can do to get mozilla to use fewer files?  (like the
recent shared library colsolidation in mail/news)
Does mozilla purge the rendered images from memory in chrome when they're not

Re: Comment #65 David Bradley
Is this still true with the GC?  Is there a bug filed about this issue?  Hmm, it
looks like bug 66381 from Comment #72 will help for this...

I can confirm Comment #68 "Wakeup 4-10 times slower when another disk intensive
app is running".  For me, when I run a apt-get upgrade in the background, it
does the same.

Re: Comment #87 From Timur Safin
Has anyone looked into this?  Is there a bug for this?

Confirming Comment #91 From Stephen P. Morse  2002-05-21 10:26 on Linux.

re Comment #171
That depends on Bug 639
Blocks: 639, 66381

Comment 202

16 years ago
Stupid me...

No longer blocks: 639, 66381
Depends on: 639, 66381


16 years ago
OS: Windows NT → All
Hardware: PC → All


16 years ago
No longer depends on: 66381

Comment 203

16 years ago
Maybe this is kind of like bug 120154? 

Comment 204

16 years ago
I don't see how this has anything to do with GIF images, also, IIRC the
processor usage isn't very high during the wait for a responsive mozilla (can
someone double check on windows?  I will check on Linux)

Also, "stupid me" was reffering to that I got the depends/blcoks dependancies

Comment 205

16 years ago
In response to Comment #192, this doesn't seem to be the case when Norton is 
running.  I have WinXP with 512 MB RAM with both Norton and Photoshop running.  
Left the machine on overnight and use Mozilla the next day, it just pop up in a 
second from the minimize state.


16 years ago
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4?
Flags: blocking1.4-
Congrats. You have now taken a bug for a somewhat specific windows-only problem
and morphed it to a general bug for a cross-platform problem that is very
elusive if present at all.  It's now poised to get a bunch of clueless people
saying it works for them on Linux and Mac.

Wakeup when the disk is busy is NOT this bug.  Wakeup when another app is
sucking CPU is NOT this bug.  This bug is about Mozilla, on Windows NT based
OSes only (not any other OS, including Linux, Win9x, Solaris, MacOSX, BeOS,
AmigaOS, OS/2) being slow to unminimize when there is absolutely no reason for
it to be slow.

The way to get mozilla to use fewer resource files is to drop all UI
customizability and just hardcode it all into the binary.  <shrug>.

In any case, I strongly recommend you undo the last batch of changes; if Linux
and OSX have similar problems, they are almost certainly caused by totally
different underlying causes.

Comment 207

16 years ago
Boris is probably right.

Garbage collection *can* make this worse (and is cross platform), but there are
some windows specific parts that this bug should focus on.  (read the traces
that were posted in previous comments.

So let's split off the other bugs reported here, there are at least two or
three.  Anyone care to help me find them?  Also, my previous questions still

requesting OS->winNT


16 years ago
OS: All → Windows NT
Hardware: All → PC

Comment 208

16 years ago
Created attachment 123323 [details] [diff] [review]
Try to force the right amount of memory to be pagead in

This is a patch that tries to do what I described in the newspost in
n.p.m.performance today. It's NT/W2k/XP only so it should only be seen as a
proof of concept patch and I don't even know if it proves anything. I would
welcome any testing or feedback on it from anyone able to apply the patch.

The idea is to use SetProcessWorkingSetSize when a window is restored after a
minimize to tell the OS that the process once again needs lots of memory.

Comment 209

16 years ago
You can't simply say that this bug is caused by the OS reducing the working
set. I did a quick test on Windows 2000 with Mozilla and IE. Opened both
browsers, browsed a few web pages, then minimised both:

VM size: 11 megs
mem usage: 5 megs

VM size: 11 megs
mem usage: 2 megs

IE6 took about 1 second to unminimise, whereas Mozilla took about 5 seconds.
It looks like IE has a larger minimum working set size, and this is making
it more responsive than Mozilla when unminimising after a period of inactivity.

This bug may be been introduced by a "fix" for bug 108475:

"If both dwMinimumWorkingSetSize and dwMaximumWorkingSetSize  have the value -1,
the function temporarily trims the working set of the specified process to zero.
This essentially swaps the process out of physical RAM memory."

The fix for bug 108475 involved adding the above function call to reduce the
minimum working set size. I suspect that this has caused the slow startup
problem, and we would be better leaving it to the operating system to determine
working set size.

Comment 210

16 years ago
You can't simply say that this bug is caused by the OS reducing the working
set. I did a quick test on Windows 2000 with Mozilla and IE. Opened both
browsers, browsed a few web pages, then minimised both:

VM size: 11 megs
mem usage: 5 megs

VM size: 11 megs
mem usage: 2 megs

IE6 took about 1 second to unminimise, whereas Mozilla took about 5 seconds.
It looks like IE has a larger minimum working set size, and this is making
it more responsive than Mozilla when unminimising after a period of inactivity.

This bug may be been introduced by a "fix" for bug 108475:

"If both dwMinimumWorkingSetSize and dwMaximumWorkingSetSize  have the value -1,
the function temporarily trims the working set of the specified process to zero.
This essentially swaps the process out of physical RAM memory."

The fix for bug 108475 involved adding the above function call to reduce the
minimum working set size. I suspect that this has caused the slow startup
problem, and we would be better leaving it to the operating system to determine
working set size.

Comment 211

16 years ago
Comparing IE6 and Mozilla for this has its flaws. Realize that IE6 and Explorer
share many things. Even when you minimize IE6 it may not get swapped out as much
as Mozilla due to Explorer still actively running. So when you restore, IE6 has
kind of a head start.

Also to correct one statement. Setting the working set size to -1 doesn't swap
the programs memory out of physical ram. It only marks the memory as available.
If nothing uses that memory before the application needs it a transition fault
occurs and the memory is reclaimed without having to reload it from the swap
file. Ideally this should be extermely fast.

Comment 212

16 years ago
Actually, I've just done some more investigation, and it appears two
calls to setProcessWorkingSetSize(-1,-1) have been removed, so unless there
are any more in the code (I haven't done a search through the entire source),
this doesn't appear to be the problem.

Maybe there should be an option to actually increase the working set, which could
be set in the preferences. The user would then be able to decide whether to
give mozilla extra ram in order to increase performance. This would go some
way to bringing Mozilla on a par with IE, which appears to be less prone to
swapping out (presumably because it's half built into the OS).

Comment 213

16 years ago
"This bug may be been introduced by a "fix" for bug 108475"

Interesting. This is bug 76831. It could not have been introduced, but could
have been exacerbated by a fix for bug 108475. 

If increasing the working set size is easy, a patch could be posted, and
interested users could give it a try. 


16 years ago
Blocks: 203448

Comment 214

16 years ago
Just another of my two cents.  Moz 1.4rc1 is just as bad as ever with this
minimize bug.  I had about 10 tabs open and Minimized Moz overnight (though 1/2
hour produces about the same result).  I took so long for all elements of Moz to
become responsive again, it was unbelievable.  Approx. 60 secs for the whole
thing to back to life.  Much quicker to shut Moz down and start over.  This is
going to be a big black eye for the whole project if Moz goes final with this
bug still as bad as ever.

THE TIME?!  I'm talking large graphic editing programs, browsers, autocad, you
name it.

Pheonix, F-bird, or whatever it's name is seems no better.

The kicker is, this is so very aggravating, but I still use Moz because it is
such a great browser in every other way....  very frustrating.

WinXP PIII 750 512 meg ram, defragged.

Comment 215

16 years ago
How about a debug build? 
One that would log time segments for every component to come up? That'd help
zeroing in on the problem? There are lots of guys who have had the bug for years
so plenty of people to submit results.. 

Personally I haven't had the problem bad for long time, but then again, I
stopped using quick start feature a year ago since it aggravates the problem. 

Comment 216

16 years ago
I'm not sure whether this is known to all: The problem is *not* limited to the
case that Mozilla is unminimized - it seems to be a general performance problem
after long periods of inactivity. Sometimes I leave Mozilla running *maximized*
over night, and when I try to poll my E-mails next morning, it's very slow for
about 20 seconds or so (Win XP, Athlon 1800+, 256 MB), even though it did not
need to redraw the window in this case. Unminimizing just makes it even worse,
probably because even more work needs to be done at the slow performance.

Comment 217

16 years ago
RE comment 216, I agree.  Unminimizing makes this problem a bit
worse but inactivity is all that is needed to make this manifest.
After a long period of inactivity, the program is unresponsive
for 15 seconds or so.

Comment 218

16 years ago
Problem is still present in Mozilla 1.4 final. Sigh ... I'm seriously thinking
about switching to Opera or returning to Internet Expluargh ...  :-(

Wouldn't it be possible to insert some debug code into Mozilla that writes time
stamps to a file (or maybe better to an array in RAM that can be read later)
after each step it performs during the reactivation phase? Maybe that would help
to find out which part of the procedure actually takes that long.

Comment 219

16 years ago
How about that debug build that logs times during come-up? 

Comment 220

16 years ago
I'm not going to bother scanning the whole sordid bug listing (which started
over 2 years ago, btw) to see if the points below have been mentioned yet, but
the developers need to know three things:

1. this problem is not limited to Mozilla, it also affects Phoenix/Firebird

2. this problem is not related to Quicklaunch (since it happens on Firebird)

3. this problem is not *caused* by minimizing, though that probably exacerbates
the problem.

- Rename this bug, e.g. "inactivity causes prolonged disk-swapping". Currently,
it sounds more benign than it actually is!
- Remove this bug's BLOCKER status for bug 108795 since I really don't think
it's related to Quicklaunch
- Fix this bug!

P.S.  I have this problem with Win2000 on a P3 system with 512MB of RAM.  I
don't even know why ANYTHING is swapped-out to disk?!  I tried disabling my
swap-file but other apps complained.

Comment 221

16 years ago
I have been upgrading to each release of Mozilla hoping that this problem would go away :( This is probably the only Mozilla drawback. However, otherwise Mozilla is such a great email and browser package that I am NOT going to switch !

Comment 222

16 years ago
Is it just me, or is this behaviour now also being exhibited by Mozilla
Thunderbird 0.1?

Comment 223

16 years ago
I'm definitely see this occasionally with Thunderbird 0.1

Comment 224

16 years ago
as far as i can tell, it's exhibited by every app that uses Gecko.

Comment 225

16 years ago
I would greatly appreciate if the developer(s) working on this bug could post
updates about his/their progress here from time to time. Otherwise we users
might get the impression that nothing is done about it.

It surprises me that a bug that probably keeps most people from using Mozilla 
on the world's most popular (though not best) operating system (XP) has still
not been labeled as a blocker for upcoming releases (severity is still set to
"normal"). Or is it just me and most XP users don't encounter this bug? Do you
have statistics?

By the way, I recommend to remove the "(minimized window)" from the bug title,
since the problem is definitely not restricted to that, as several users have

Keep up the good work!

Comment 226

16 years ago
FWIW, I have never had the problem on my home machine (1024MB RAM), but do have
it on my work machine (256MB RAM) with Firebird.  The former has the swap file
turned off, but the latter does not (set to the default 1.5 * amount of RAM). 
Both run WinXP.  It seems like 512MB is around the switchover point based on
previous comments with and without problems.  If this is a working set issue, is
this size somehow calculated based on the total amount of RAM?

Comment 227

16 years ago
I recently upgraded my XP PC from 256 to 512 MB (keeping the default swap file
settings), but as far as I can see, that did not change anything - problem still

Comment 228

16 years ago
I'd be interesting to know what the value on Task Manager is in the Physical
Memory (K) area by "Available" reads. Is this less than 6,000 k for the people
seeing this problem?

Comment 229

16 years ago
OK, I checked on my system (Windows 2000, 384 Meg of memory) by starting various
applications.  With 116,340 K showing as "Available" in the task manager, I am
starting to see this problem.  (I used Thunderbird 0.1 to test.)

Comment 230

16 years ago
I'm not sure if this is relevant, but I haven't noticed this bug as much since I
started avoiding "minimize". I was using the Windows meta key with "m" which
minimizes all windows. This bug annoyed me so much, I started using <Windows>-D
to "display desktop", which I suspect is different than minimizing all windows,
even if it achieves a similar effect.

I don't seem to encounter this bug as much this way. Maybe this might help
determine what is going on.

I'm testing with two systems:
- WIN2K 600Mhz 512MB
- WINXP 900Mhz 640MB
1.5GB swap on each. Max memory usage never peaks over approx. 280MB in Task Manager.

Comment 231

16 years ago
joerg: thank you for volunteering.
Assignee: bryner → bugzilla

Comment 232

16 years ago
I checked the available physical memory under XP in two cases while the problem
was present in Mozilla 1.4. It was around 200 MB in one case and around 300 MB
in the other (some other apps were running as well). I have a total of 512 MB.
So I don't believe this is a problem of too little physical RAM. Also, I didn't
notice a significant change in the memory numbers while the problem disappeared
(it generally seems to disappear gradually, not suddenly). The problem also
doesn't eat up the CPU power.

Comment 233

16 years ago
Mostly likely what's occuring is that once Mozilla is minimized Windows begins
taking the pages put in transition and using them for disk cache.

I really think the two issues at the heart of the matter are the GC routine
having to ouch many block of memory causing a large portion of the app to be
paged in even when those objects may not be actively used. And then possibly the
fragmentation of objects across pages. As GC occurs and/or objects are access
they don't hit pages sequentially as they were stored, but at fairly random
distances. This causes the retrieval to be even slower than just reading the
same amount of data sequentially from the disk. This might explain why some
people's system it's faster to just terminate the application and restart it.

From your description, available memory being up, low CPU usage during
restoration is the symptoms of paging. Was there a fair bit of file I/O while
you had Mozilla minimized? See my comment 211 for an explanation of what's going
on here.


16 years ago
Summary: slow startup after long periods of inactivity (minimized window) → Slow startup after long periods of inactivity

Comment 234

16 years ago
Thanks, David - it looks like your paging theory is correct. I just minimized
Mozilla at normal performance, then copied about 2 GB of files from one HD
partition to another (took about 15 minutes), then restored Mozilla and indeed
it was slow (though not as slow as in the worst cases).

This would also explain why the problem seems to appear randomly and definitely
not directly dependent on the time that has passed (sometimes it restores just
fine after several hours of inactivity). If it depends on disk activity, then
it's clear why the problem occurs every morning on my PC, because Windows does a
HD backup of all my data each night.

Is there a way to disable disk caching in XP to verify your theory?

By the way, I removed "(minimized window)" from the bug description because the
problem is not limited to that case. (For some reason this bug was assigned to
me yesterday though I did not request or agree to that and I'm no expert, just
an ordinary user ...)

Comment 235

16 years ago
AFAIK, the age-old settings for controlling disk cache work in XP as well. In
your Windows folder, there will be a system.ini file.  If it has a [vcache]
heading already, put the settings under it; if not, add it.

Try something like:

which will make the cache size 1MB.  There's probably a setting to disable it,
but limiting the size should do for this purpose.

Comment 236

16 years ago
Limiting the cache will only serve to reduce performance on apps accessing a lot
of data on disk. For instance, the mozilla build doesn't require a ton of
memory, but having a large disk cache available really speeds things up. All the
include file data can be kept in memory. It might serve as an interesting
diagnostic, though.

Comment 237

16 years ago
Michael: As fas as I understand, the system.ini file is for legacy 16-bit apps
only, so I didn't use that to adjust the disk cache.

Looking around on the web, I found that XP seems to control the disk cache with
the following registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\IoPageLockLimit  (DWORD, cache size in kilobytes)

Interestingly, that value didn't exist in my registry at all, so I added it and
set it to different low values: 0 KB, 1 KB, 512 KB, and for comparison a large
value (256 MB), then rebooted each time and repeated the "Restore Mozilla after
a lot of file copying" test. However, I did not notice a significant change, the
problem remained visible in all cases. Then I activated the option
"DisablePagingExecutive" (found in the same registry branch, changed from 0 to
1), but this didn't remove the problem either.

Since the amount of performance loss always varies a bit, I cannot guarantee
that the changes had *no* influence, but obviously the problem could not be
removed by a low disk cache. Maybe this helps anyway for the diagnostics.

Comment 238

16 years ago
In response to comment #234, you folks may be on to something.  Mozilla
experienced no problem when I left it open all night and browse around in the
morning.  Then I had to do the CD burning, so I copy all of the file off of the
CD onto the HD since I only have one CD drive.  Then put in a new blank CD to be
burned.  Once the CD burning was done, I haven't touch Mozilla for 30 or 45
minutes and unminimized it, it took a while to unminimize.  I have not yet
deleted the file from the HD.  30 or 45 minutes is enough time for the virtual
memory to take care of itself.

I use WinXP with 512 MB of RAM and 9 GB of HD with 2.78 GB free.


16 years ago
Flags: blocking1.5b?

Comment 239

16 years ago
Joerg, Zook:

Re comment #238: paging/swapping out is being mentioned starting with comment #4
and not a very new idea.

Re comment #225:
> [we] might get the impression that nothing is done [...]

Did it come to your mind that maybe there is actually nothing being done currently?
For doing something there is always somebody necessary who does it.

> I recommend to remove "(minimized window)" from the bug title

Finally you did it yourself, but did you consider the fact that this part was
added to the summary due to all the duplicate bug reports which often included
"minimized" in their summary? This addition should - and did - help decrease the
number of duplicates being reported.

> It surprises me that [this] has still not been labelled as a blocker ...

It does not surprise me because it seems to be a problem that is not easily
fixed. If bugs with no fix in sight for months (or no fix without changing the
whole way Mozilla works) would block releases, no releases would me made for months.
You surely have read comment #199, haven't you?
It also does not block you from using Mozilla. I know these seconds hurt (I also
don't like it), but the definition of a blocker is different.

Re comment #234:
> For some reason this bug was assigned to me

Well, after demanding response from "the developer(s) working on this bug",
changing the summary etc. aren't you surprised that you look like the mighty
driving force for this bug?
Demanding progress in open source means stepping in and filling the gap.

Re [other comments, e.g. comment #145, comment #154, comment #191, comment #200,
comment #214, comment #220,....etc....]:
> [this bug is bad and should be fixed] [I'm sadly switching back to IE] 
> [This is a serious bug] [WHY IS MOZ DOING THIS SO BAD] [Fix this bug!]

This is no newsgroup!! Because of such nonsense this bug has more than 200
comments and is nearly useless - or have you all read every comment before
posting? Things are repeated over and over, knowledge is lost, sometimes
rediscovered as "new" later...
It's just sad how poor some people's knowledge of how bugzilla is supposed to
work is.
Yes, this comment does also not help solve the problem, but it might (hopefully)
prevent several even more useless ones from being written. 
Nothing against_really_ helpful comments (there are several ones), but please be
sure your's is one before hitting "Commit"!

Comment 240

16 years ago
Andreas Kunz from Comment #239 made a point about Comment #4.  It had eluded me 
because of so many non-sense comments that I no longer remember the true 
meaning of it.


16 years ago
Summary: Slow startup after long periods of inactivity → Slow startup after long periods of inactivity (minimized window or other)
Whiteboard: [adt2 rtm] → [adt2 rtm] [swapped to disk]


16 years ago
Flags: blocking1.5b?

Comment 241

16 years ago
Update from my previous comments:  I've just built a new machine. AMD 2500 chip
(2+gig mhz) fast 333 motherboard with fast 333 memory (512meg), new 80 gig hard
drive, fast ATI video card.  The minimize bug is (if possible) even worse on
this rocket machine (or it just seems worse, since all other programs are twice
as fast now, and Moz still slogs through the mud).  I had hoped on this new
machine, all the Moz sloggyness would vanish, but alas, it's just as bad as ever.

I can't tell from any of the comments here, but is ANY progress being made on
this very aggravating bug?

Comment 242

16 years ago
I get this problem too. I have 384 mb of memory which should be enough for
efficient memory swapping but I still recieve this bug .                       

Comment 243

16 years ago
I too have this problem and it's the main reason I switched to Opera as my
default browser. I prefer Mozilla Firebird but this bug (Which only happens with
Firebird) is a major annoyance.

I'm really hoping that this gets fixed but seeing how long it has been I'm kinda
doubtful now. Seems it would require more work than the devs are willing to put
in to this non-blocking issue.
System Specs:

1 Gig PC2100 RAM
Dual 2.4G Xeons (HT enabled)
2xCheetah 15000 RPM drives in RAID-0 Config (Browser runs off this)
Windows XP + SP1 and all the latest patches
*** Bug 219343 has been marked as a duplicate of this bug. ***

Comment 245

16 years ago
It may be of interest that OpenOffice (I have version 1.0.3) shows the same
problem on my PC, though the delay is much shorter than with Mozilla. As far as
I know, both programs draw their user interface themselves without using a lot
of Windows GUI function calls. Maybe this helps to track the problem down.

Comment 246

16 years ago
I have been doing some research on this bug for quite some time (from time to
time).  I just happen to saw an useful article on how to use the Windows NT
Kernel Debugger at
 This article is very general and very lengthly, all we only need to do is to
look at the disk activity section.  Not too familiar with the debugger myself
but I believe it would help to narrow down the problem to certain features that
is responsible for this bug.  I'm going to give this a shot.  Keep me post on
the development progress on this bug.  No useless comments please.

Comment 247

16 years ago
I managed to capture a log of what files mozilla 1.5b was trying to access while
waiting for the window to appear after leaving it alone for a long time. It's
not complete, as it took time for sysinternals filemonitor
( to start up, but something about the log struck me as

Over the course of about 45 seconds while mozilla was non-responsive, there were
very few accesses to the swapfile. Far more accesses were made to font files.
There were many pauses between accesses to fonts with no disk activity
whatsoever; not even to the swapfile. 

Might it be the case that the pausing has something to do with fonts, rather
than paging?

I'm running mozilla 1.5b on windows XP, 512MB RAM, 256MB swapfile, mozilla (post
restore) 80MB working set, 320MB VM size. 25 windows, 200-odd tabs open.

Comment 248

16 years ago
Created attachment 132097 [details]
Log of mozilla 1.5b's file accesses while recovering from inactivity

Hopefully this is useful in some way. If not, sorry for wasting everyone's

Tab separated text, should import into a spreadsheet program for easier

What I find interesting is that there are several accesses with many seconds's
pause between them but no other accesses (for example 155-156 is a gap of ten
seconds; 205-206 14). Mozilla became responsive again some time around 22:24:50
or so.

Comment 249

16 years ago
That's an interesting observation about pinging the font files repetitively.

I have a couple of questions about the filemon data: 1) was this done in the
'advanced mode' setting? If not, you won't see paging activity [by design]; 
2) why is the swap file called WIN386.SWP? On NT/2K/XP isn't that normally called
'pagefile.sys'? Is this an XP that was upgraded from a win9x install?

Comment 250

15 years ago
*** Bug 220896 has been marked as a duplicate of this bug. ***

Comment 251

15 years ago
Created attachment 132557 [details]
TaskInfo2003 information concerning Mozilla

Perhaps this extra info may tweak someone's head.

Does the Virtual KB seem reasonable?
Do the Fault Counts?
Do the GDI's seem reasonable?
Does the number of Modules?
The size of the Handle files?

Hope this helps.

P.S.  Windows Task Manager's VM Size only showed 64,100.

- Mark

Comment 252

15 years ago
Well, I don't know if the bug has been officially fixed but I downloaded and
installed the latest 0.7. I'm running a version optimized for my P4. The slow
restoring problem has disappeared or is so small as to be unnoticeable.

Comment 253

15 years ago
I take it back. I just experienced it again but it seems to take longer to get
to the point where it restores slow. Also it still faster than it was but when
it does it, it's very noticeable.

Comment 254

15 years ago
*** Bug 206341 has been marked as a duplicate of this bug. ***

Comment 255

15 years ago
If you want to see this bug in the worst intensity that's probably possible, get
the X-Plane flight simulator (the free demo from should do the
job). Start and minimize Mozilla, then start X-Plane and shut it down again.
Then restore Mozilla - it's almost frozen to death on my system (Win XP, 512 MB,
Moz 1.4). It takes several *minutes* to return to normal.

Comment 256

15 years ago
I noticed that if you change the process priority to high sometimes Mozilla
"awakes" faster. A few days ago I opened the Task Manager while Mozilla was slow
reloading, and noticed that he was increasing the memory used bue at small
chunks (usually other programs take bigger chunks) while the HDD light was
permanently on, so I increased the Mozilla process priority and Mozilla started
to take bigger memory chunks (or the same size chunks but faster). This was
after closing a game (Quake 3), and the processor was almost unused (Mozilla
wasn't taken even the 50% of the CPU), and all open process had normal priority
but taskmgr, winlogon and CSRSS.
I have an Athlon 1700+ with 512MB using Win2k SP3 and Mozilla 1.5.

I also noticed that Mozilla goes slower than other programs if any process is
taking the 100% of the CPU. In that conditions IE and other programs take more
time to load that with and idle CPU, but Mozilla takes ages to start or show a page.

This behaviour is like Mozilla have a lower priority than other "normal" processes.


15 years ago
Assignee: bugzilla → jag
QA Contact: jrgmorrison → pawyskoczka

Comment 257

15 years ago
*** Bug 227654 has been marked as a duplicate of this bug. ***

Comment 258

15 years ago
Some of the bugs that are duped to this one, mentions a slowness after a
sleeping period. They might suffer from the swapping prioblem too, but they
might have their specific problems on top of that. Compare for example with bug
197863 (High CPU usage after waking from sleep because of timers). The solution
was only implemented for the Mac at
but can we use a similar thing for Windows ? See also bug 639.

Comment 259

15 years ago
I agree with Jo Hermans. Tough I also experiment the slow restart of Mozilla
after long time being minimized or inactive (specially after being playing with
games), the behaviour is different of the problem that happens after restoring,
since then  the entire system freezes, not only Mozilla (this was described in
the bug 206341). Also, I only notice that behaviour when I left open pages with
some Macromedia Flash content (see the bug 206341 for a detailed description).

By the way, after upgrading to Mozilla 1.5 the suspend/hibernation problem
almost disappeared in my Windows 2000 system, and mitigates in my Windows XP
system (now the delay is 1 minute at much instead of 2 or 3). The problem of
slow start almost minimizing affects my systems more or less the same. I have
installed Flash 7 now, but I think that it was the same behaviour with Mozilla
1.5/Flash 6.

Comment 260

15 years ago
Can it be cured by ?


I am evaluating 7-max (from the makers of 7-zip) and with both Firefox and
Thunderbird running, they do seem zippier. I wonder if some of you could confirm
my suspicions, and if they are correct, would they accept a "strategic alliance"
? :)


Comment 261

15 years ago
Comment #260:

Replacing Windows components (even only temporarily in memory) is a BAD idea.

Comment 262

15 years ago
It might be an option for users that want to install that, but I wouldn't want
to make such a change at install time of an application. And moving from 4k to
4m pages have other implications. Given each app has a finite address space, it
might use up the address space quicker.

While there might be a perf boost, I would bet the problem still exists. Paging
might be more efficient since depending on how the Windows paging system
reads/writes pages. Writing 4meg at a time would be more efficient than 4k at a

I still say the biggest boost would probably come from the addition of Shaver's
generational GC work.

Comment 263

15 years ago
I've just found a way to reproduce the behaviour on demand:

1 - open a goodly number of tabs/windows 100 tabs over 10 windows should do on a
0.5Gb machine.
2 - Open the display properties control panel, and change the colour depth
3 - when asked if you want to keep the setting, answer 'no'.

At this point, mozilla will exhibit the 'slow startup' behaviour. In addition,
all the taskbar icons change from the individual component's icon to a generic
'red mozilla head' icon.

It would seem that mozilla is doing a lot of unnecessary repainting/reflowing
and is not usable until it has done so. I don't know enough about mozilla to say
why this is happening.

A log of mozilla's file activity shows it doing a lot of accesses to the fonts
folder. You'll notice a lot of disk activity, but investigation with something
like filemon will show that this is caused by explorer.exe rebuilding its icon

After repeating the procedure a few times, I was able to get mozilla to 'slow
startup' without accessing the swapfile at all. In my opinion, this has nothing
to do with paging.

I suspect this is happening on NT after periods of inactivity, because NT has
more than one desktop. Under NT, the screensaver is executed on the 'secure
desktop', over the top of the logon/unlock screen (so crashing/killing the
screensaver does not unlock the computer). I suspect the desktop change (like
the colour depth change) is triggering this repaint behaviour.

re comment 249, the swapfile has been changed from the default filename, so as
to make dual-boot XP and 98 use the same swapfile. The log was taken under XP,
advanced mode off. I can send you an advanced mode log if you are unable to
reproduce using this method, but I'm reluctant to post it on bugzilla, as
explorer.exe trawls most of my hard drive looking for icons.
Has anyone tried with a static build to see what difference does it make if
there aren't dozens of dlls to swap in?

Comment 265

15 years ago
I know that alecf had been working to reducing the DLL count, so I assume there
were some numbers suggesting it was a good thing. Also there is or was a static
lib build option I thought.

Comment 266

15 years ago
*** Bug 231232 has been marked as a duplicate of this bug. ***
I have just found;en-us;293215
via a comment at

That KB article seems to imply that intercepting SC_MINIMIZE and turning it into
SW_SHOWMINIMIZED should prevent the application from being paged as much as it
would with the default behavior of using SW_MINIMIZE.

Since I'm not a Windows programmer (I'm not even a Windows user) I don't know if
this will help or not, but since nobody mentioned it yet, I figured it might be
useful. Sorry for the spamming if it isn't (but if you are in the CC list for
this bug after all this time, you already expect it, right? ;-)

Comment 268

15 years ago
Created attachment 144180 [details] [diff] [review]
don't reduce working set when minimized

That's an easy change. It probably fixes this bug, but makes a real memory hog
out of Mozilla. On my machine with an optimized build, according to the Task
Manager memory usage is (in Megs):

						  prepatch     patched
launch one window, about:blank			    18.3	 18.2 in one window, in a second	    25.0	 24.7
minimize				     8.2	 24.7
minimize both					     1.8	 24.7
restore both					    10.7	 24.7

In the unpatched build, memory usage doesn't return to its 25 Meg peak until a
new page is loaded.
Comment on attachment 144180 [details] [diff] [review]
don't reduce working set when minimized

Well, I think this patch might be a great thing. I find it stupid to trim the
working set when an app is minimized -- like I didn't need it anymore or it
didn't do anything in the background. Might be a good idea to check this in
when the trunk is opened again to gather feedback.

However, it still puzzles me how swapping in can be so slow sometimes. I've
witnessed this on my Athlon XP 2400+ 256MB WinXP system when there are two
people logged in having Mozilla and other programs running. It can take
something like two minutes of horrendous swapping for the Mozilla in the
previously inactive session to start responding again when the user is

Comment 270

15 years ago
Whoa!! The patch would need to be tested a couple of times or more by different
users/machines to see if it is not causing any problems and/or to see if the
problem is actually solved before checking it into the trunk.

Comment 271

15 years ago
And you might want to make it a configurable option (maybe a hidden one?).  I
can see some folks preferring the delay to the constant memory use.  It
certainly is a non-ideal solution, IMO, so its desirablility would likely depend
on your particular memory resources/needs.

Comment 272

15 years ago
maybe someone could provide a teste build. Dan?

Comment 273

15 years ago
25 meg is a small price to pay for this most annoying bug.  Even if I had to run
a one-off build.  I'll gladly test a build of this as I've been suffering from
this minimize bug terribly from the beginning.

WinXP and Win3k

Comment 274

15 years ago
danm proposes landing a variant of this patch that makes the change depend on
setting a ui-less preference.  Need a patch doing that to proceed.  Nominating
for 1.7 final.

Flags: blocking1.7?

Comment 275

15 years ago
Created attachment 144414 [details] [diff] [review]
don't reduce working set when minimized, configurable

Same as comment 268, but this version is configurable using a pref. It behaves
as it always has if the pref is missing or true. (Oh and, ahem, I cleaned up a
deprecated use of nsIPref while I had the hood up.)

I don't know that this will fix the thrashing problem, but it seems worth
finding out. I don't have a suitable server for posting a test build. Perhaps
some people affected by this problem could spin their own build. Or maybe we
can get this configurable version into the general 1.7 release.


15 years ago
Attachment #144180 - Attachment is obsolete: true


15 years ago
Attachment #144414 - Flags: review?(ere)

Comment 276

15 years ago
Everybody seeing this bug:
I made a build with that latest patch and made it available at

My bandwidth is large, but not unlimited, so please send me a short note (by
e-mail) when you're downloading it, so I get a rough estimate on how much
bandwidth is used.

After downloading, you have to set the pref "config.trim_on_minimize" to "false"
to activate the patch, at least that's how I understand the patch. DanM, please
correct me if this is wrong.

Thank you and good luck for testing this!!

Comment 277

15 years ago
(In reply to comment #276)
> After downloading, you have to set the pref "config.trim_on_minimize" 
> to "false"

To explain this: you have to access about:config and create a new boolean pref
with this name, value being false.
I just tested it and it works (Task Manager shows mem values on minimize that
are very different from when this pref is set to true).

What I also noticed when testing, was that this tree of mine had a preliminary
patch for bug 155325 applied. But be assured, apart from that it is a fresh cvs
pull from a few hours ago and that patch should not affect testing. 
(it is about showing scrolling errors when you have many tabs open to prevent
them to get to small or to fully disappear on the right. This patch is not
ready, so you don't need to comment in that other bug when you find small glitches).

Comment 278

15 years ago
(In reply to comment #276)
> I made a build with that latest patch and made it available at
> My bandwidth is large, but not unlimited, so please send me a short note (by

I downloaded your test build and it's available on:
Comment on attachment 144414 [details] [diff] [review]
don't reduce working set when minimized, configurable

Looks good, r=ere
Attachment #144414 - Flags: review?(ere) → review+

Comment 280

15 years ago
>>After downloading, you have to set the pref "config.trim_on_minimize" 
>>to "false" to activate the patch, at least that's how I understand 
>>the patch. DanM, please correct me if this is wrong.

In respond to comment #276 and for comment #278, which file exactly for the
zipped  archived??  I couldn't find one that contain the word,
"config.trim_on_minimize".  I'm sure everyone else would want to know this too.  

By the way, I can test this with the disk activity for WinXP monday morning to
see how it goes and will let you know.

Comment 281

15 years ago
(In reply to comment #280)
> In respond to comment #276 and for comment #278, which file exactly for the
> zipped  archived??  I couldn't find one that contain the word,
> "config.trim_on_minimize".

Didn't I clearify this in comment #277?

There is no such entry yet in a prefs file, you can set that pref easier anyway
by typing "about:config" into your URLbar and hitting return. Right-click on the
appearing list, choose "New" - "Boolean", then enter "config.trim_on_minimize"
for pref name and then "false" for its value.

What I didn't mention: you might have to restart Mozilla after adding this pref,
maybe not, but you're on the safe side if you do.

I did only a short test, there was no lag with the patch, almost no lag without
the patch. I obviously didn't manage to swap it out enough. Not enough
difference to say if this only was what I _wanted_ to see.

Comment 282

15 years ago
Yes, after setting this pref using about:config, be certain to quit and restart.
The preference is read only once, early during app initialization. (Your other
choice is to edit prefs.js using a text editor.)

Comment 283

15 years ago
Will this pref also be read from user.js?  Modifying prefs.js is not recommended.

Comment 284

15 years ago
I am no longer able to reproduce this bug with Mozilla 1.6 which I downloaded at
the time of that Mozilla 1.6 release.  So, I can't test the last week build with
the patch attached.  Hopefully someone else who have this problem can come
forward to test it and let us know how it go.  

By the way, I think it would be wonderful if this patch is checked into the
trunk because it could help to ease or to resolve other bugs not related to
this.  Well, if that doesn't hurt other bugs or produce new bugs.

Comment 285

15 years ago
(In reply to comment #283)
> Will this pref also be read from user.js?  Modifying prefs.js is not recommended.

Answering my own question, the pref does get read from user.js if it is set there.

Comment 286

15 years ago
After a few days of looking around w/ Mozilla, I found that if I left the
JavaScript Console running in the background while MS-Outlook in the foreground.
 Left it there like that overnight then try to bring the JavaScript Console to
the foreground, it took almost 10 minutes for it to become responsive.  In the
task manager, it showed that about 200 MB of memory/paging was used to bring the
JavaScript Console back.  Once it become responsive then 200 MB of memory/paging
goes away.  So, I thought perhap this is it for testing.  So, tested it w/ and
w/out the patch for a couple of overnights.  There I found the JavaScript
Console become responsive instantly, or by a second.  Seem like the patch fix
did the trick.  

By the way, I'm using WinXP with 512 MB of RAM which would have been kind of odd
without the patch fix.

So, anyone want to super review the patch?  Anyone want to try to get it checked
in?  I don't think it would hurt to give it a shot.

Comment 287

15 years ago
Comment on attachment 144414 [details] [diff] [review]
don't reduce working set when minimized, configurable

That's odd. I wouldn't expect this patch to affect windows that are merely
backgrounded, rather than minimized. I think it needs more testing. But maybe
we're onto something. Cesar, thanks for finding that bit of Windows trivia that
made the patch possible. And thanks Zook for running it through its paces.

It's worth getting sr=ed and I think put into 1.7 where it can reach a wider
audience, since it's inactive by default, anyway.
Attachment #144414 - Flags: superreview?(bryner)
Attachment #144414 - Flags: approval1.7?

Comment 288

15 years ago
Doesn't making it off by default make the patch worthless ?  Most users will be
unaware of the setting and will continue to be affected by the performance hit.
 If you want it to receive more attention (testing) perhaps ask one of the
unoffical builders on mozillazine forums to include it (set to on) in their
builds and let it get thrashed out that way.

Comment 289

15 years ago
(In reply to comment #288)
> Doesn't making it off by default make the patch worthless?  

This patch causes Mozilla to use dozens of Megabytes more when being minimized.
Are you joking or do you really expect users will like it behaving this way by
Apart from that the effectiveness of this patch has not been completely tested,
there is only about one positive response. That's not much of a legitimation to
get it into a final build without ever having been in a beta.

> Most users will be unaware of the setting and will continue 
> to be affected by the performance hit.

Of course, but 1) the default can still be changed later and 2) it's certainly
nicer to be slow than to make everything else slow. Imagine the bad press when
people say "Mozilla slows your system down by intentionally hogging RAM with the
aim to run faster than other applications!".
I doubt this should ever be on by default.
(BTW, the real bug - paging in is extremely slow - is not fixed by this
wallpaper-like patch.)

>  If you want it to receive more attention (testing) perhaps ask one of the
> unoffical builders on mozillazine forums to include it (set to on) in their
> builds and let it get thrashed out that way.

Huh? With this patch it's as easy as setting a pref for everybody having a
standard build to test this. You think people are more willing to download a
dozen MB than to set a pref in 1.7?
If you just want to have more people test this, they can as well download this
build here and set the pref. But of course making the test build public in the
mozillazine forums isn't a bad idea. Please feel free to do so!

However, this bug has 87 votes and about as many people cc'd. One would assume
they are interested in getting this bug fixed, right?
Then how comes that I only know of two people having downloaded the test build
from my site for testing?

Maybe my message about bandwidth caused the majority of the testers to download
from Adam's mirror, but even if so, there (almost!) hasn't been any testing
response. People, voting for bugs is nice, but don't expect it to actually help
fixing bugs...
(I have an excuse: my mainboard is out of order and I'm working with a Pentium
120 and Win95 right now...)

Comment 290

15 years ago
I've been running this patch for a week or so and have had great results.

There haven't been any instances where firefox hung, where before this, I found
it a few times a day.

Comment 291

15 years ago
If a user has a low-memory system (i.e. 128 MB or less) then it is absolutely a
BAD idea to not allow Mozilla to give up it's non-essential paging space while
minimized.  Many people keep they browser minimized when not in use so that it
can continue to check for E-mail, refresh web pages, etc.

Sure, if you have lots of spare RAM on your machine it might help you, but I
think we should first consider the possibility of how memory management is
handled in Mozilla as a root cause.  For instance, you can get Mozilla to expand
to 128MB of real and VM usage by loading a very large .JPG file.
One clarification: this patch does _not_ prevent Mozilla from releasing memory
for other apps (that is, being swapped out). It's just that it won't happen
before it's necessary, and only the needed amount of memory is "moved" from
Mozilla to the other program. This is the same thing that happens if you leave
Mozilla to the background and start another program.

Comment 293

15 years ago
Let me just say I've been running Andreas Kunz's fix build and it's fantastic! 
I'll gladly sacrifice the 20-50 megs ram to see this problem fixed.  I've run it
for hours on end (minimized with a dozen or more tabs) and it pops up instantly.
I'm keeping this build as my default.

Thanks Andreas!

Comment 294

15 years ago
No it doesn't prevent Mozilla from being swapped out. But it will cause memory
to be paged out in other applications that aren't minimized, that ordinarily
wouldn't have had to.

Generally the idea is that if an application is minimized, it isn't being used,
and that it's better to ask for memory from applications that are minimized than
ones that aren't.

I think the pref is an excellent idea, but I think turning it on by default
could be a mistake unless the majority of Mozilla users only run Mozilla and no
other memory hungry applications. It would be interesting to know what the
percentage of users who leave their browser up and running for long periods of
time as well as the percentage of users experiencing the problem.

I'd just like to see that if we would turn this on by default we wouldn't be
ticking off an equal number of users. I know for my usage, I'd have to go back
and turn it off.

Comment 295

15 years ago
I agree that wider audience is neccessnary to test this out.  We have like less
than 100 people who are CC's here as oppose to 10,000 people out there on
Internet.  So, more opportunity out there.  The feature is off by default,
contain only a few lines of codes, so it is not to kill anybody over it.  An
analogy of this would be a heart patient with or without a pacemaker.  Just that
symptoms are reduced.  This patch could help to connect the dots for other bugs
not related to this, so this is a plus!  Everybody win!  There is no loser here!

Comment 296

15 years ago
I downloaded Andreas' test build and tried it with the ultimate memory killer
application - after loading and closing the X-Plane flight simulator, my
standard Firefox reproducibly got very slow for 20-30 seconds. The Mozilla test
build reduces this time to maybe 3-5 seconds, which I find acceptable and is
comparable to some other applications. Thanks for the great work, especially to
Andreas! If someone could provide a Firefox build with this patch, I'd gladly
test it, too.

Still I hope the underlying paging problem will be addressed as well.

Comment 297

15 years ago
Since the problem is really aggravated by the so-called quick start feature
which actually makes mozilla real dog.. It would be nice to have UI tick box
right next to the "quick start" option in preferences for conservative memory
usage. Not many people read mozillazine and/or release notes. 

Comment 298

15 years ago
> especially to Andreas

Don't thank _me_, I only compiled the test build. I consider Cesar Eduardo 
Barros the real "hero" - he had the idea for the patch in comment #267.
And of course Dan M actually writing the patch. Thanks!

I only hope this patch will not keep us from eventually finding out why Moz is 
paged in so slowly. But since we did not find out in years, I have no hope this 
will happen soon and am really happy to have this pref available.

BTW: as already pointed out by ere, Moz _will_ be paged out, but only when it 
really needs to be. This means other applications are not slowed down that 
much, maybe it's not even perceivable.

Comment 299

15 years ago
In reply to comment #297 about quick start feature.  Are you saying that if the
quick start feature is enabled, it aggravate the problem?  Mine is disabled the
whole time.

Comment 300

15 years ago
I downloaded that patch but it's for Mozilla. Is there a Firefox specific patch
that I can try?
Comment on attachment 144414 [details] [diff] [review]
don't reduce working set when minimized, configurable

You know, I'm really not a fan of the new pref interface needing more virtual
method calls and null checks than the old interface.  Not much to be done
though; you're using the interface correctly.

sr=me.	Let's try to get some testing on this in 1.7 so we can make a decision
about turning it on for 1.8.
Attachment #144414 - Flags: superreview?(bryner) → superreview+

Comment 302

15 years ago
Comment on attachment 144414 [details] [diff] [review]
don't reduce working set when minimized, configurable

a=chofmann for 1.7
Attachment #144414 - Flags: approval1.7? → approval1.7+

Comment 303

15 years ago
Stormblade (comment 300): The patch is general and applicable to both Mozilla
and Firefox. And Thunderbird and every Windows app, for that matter.
Brian (comment 301): I've never understood why the new pref interface was
better, either. But somebody said "deprecated," so here we are.

Patch is checked in to the trunk. So reiterating, it causes no change in
behaviour by default. But if you're suffering from this bug and you're
uncommonly knowledgeable, you'll be able to set a pref which will prevent
Windows from reducing the application's working set when minimized. Please do
give it a try and report your results.

To set the pref, navigate to about:config. Create a new boolean pref using the
content area context menu. Its name is "config.trim_on_minimize". Set its value
to false. Exit and relaunch the app.

This capability will be in the nightly builds beginning tomorrow, and barring
accidents, in the 1.7 final release. Thanks again to Cesar, who doesn't even use
Windows, for discovering the trick.

Comment 304

15 years ago
Given the CC list size and number of comments in this bug. Would it be a good
idea to spin off a separate bug to receive input from the impact of this patch?
Then only people really interested would be putting themselves on the CC list
and it would make it easier to get to this information.
(In reply to comment #282)
>The preference is read only once, early during app initialization. (Your
>other choice is to edit prefs.js using a text editor.)
So, not switch-profile safe ;-)

Comment 306

15 years ago
Since the patch had been checked in to the trunk on 04/01/04 and the roadmap
showed that the Moz 1.7 would be branched from the trunk on 04/02/04.  Yes, we
know the roadmap is only a guideline and sometime doesn't happen on-time.  So,
is there a valid reason that this patch should be blocking the Mozilla 1.7
release as it is right now?  Unblock it?


15 years ago
Flags: blocking1.7?
Furthermore, does this patch do anything at all on the Linux OS, or is it
Windows-specific? If it's Windows-specific, then Mr. Valem's suggestion about a
spinoff bug should be Windows-themed and this one should be kept open to fix the
problem on ALL operating systems.

Comment 308

15 years ago
(In reply to comment #307)
> Furthermore, does this patch do anything at all on the Linux OS, or is it
> Windows-specific? 

This bug is Windows specific (as suggested by the OS field and the first about
200 comments). Only then somebody said that unminimizing on Linux also was not
_that_ fast. But this was clearified in comment #206 and comment #207 (which you
really should read).
Setting the pref to false is working like a charm for me !
Thanks all !
This should be false by default. Mozilla should not attempt to override the OS
memory management. Windows will automatically trim mozilla process memory (and
other processes as well) when it's needed (ie when running low on memory).
There's no need to trim the memory if there's plenty of MB RAM FREE and Mozilla
currently has no way to know about this, only the windows OS knows.

Comment 310

15 years ago
But this is what Microsoft recommends, and what every other application running
on Windows does to be a good citizen. If applications didn't do this, then every
application is on even footing for getting memory reclaimed. Which is generally
not a good thing. The act of minimizing was used to allow intelligent reuse of
memory so that active applications were allowed to keep the ram they had and not
be forced to fault it back in.

I really think having Mozilla be a good neighbor by default is better than
having it be a bad one by default.
oops, sorry ...
I've just tried minimizing IE and Winword and their process memory is trimmed on
minimize. I misunderstood mozilla behaviour.
David: you're right
I reverse my Comment 309 conclusion ie the current default pref value (true) is
correct, Mozilla just match Windows OS policy.
The initial problem remains. 

Comment 312

15 years ago
(In reply to comment #310)
> But this is what Microsoft recommends, and what every other application running
> on Windows does to be a good citizen. If applications didn't do this, then every
> application is on even footing for getting memory reclaimed. Which is generally
> not a good thing. The act of minimizing was used to allow intelligent reuse of
> memory so that active applications were allowed to keep the ram they had and not
> be forced to fault it back in.
> I really think having Mozilla be a good neighbor by default is better than
> having it be a bad one by default.

True, but Mozilla plays the game like a retarded monkey, otherwise we wouldn't
be having this conversation.  I say, have this new pref disabled by default but
have a damn clear UI setting to turn it on.  Actually, it would be kind of
embarrassing.  The developers would be admitting they wrote something they can't
fix correctly.  Still, I'll take it.


15 years ago
Keywords: fixed1.7

Comment 313

15 years ago
Can we get this switch documented (what it is, how to activate it) in the next
Release Notes?  I've already forgotten what the setting was called (I know, it's
in the history of this bug . . . somewhere!)

Comment 314

15 years ago
Could someone summarise here?  I just can't sit here and read the vast number of
comments in this bug.  

I'm seeing the same problem with mozilla's process size growing from 20Mb to
60Mb paging in at 200kilobytes/sec - horribly slow.  You can see the process
size growing in the task manager, under the process list.

I'm running 1.7b.  I gathered from some comments above that I need to put this
in prefs.js, is that correct?  Is this patch in 1.7b?

user_pref("config.trim_on_minimize", false);

Comment 315

15 years ago
relnote keyword added (sounds like a good idea to make this public)
(sent private mail to David about etiquette; 1.7b does not feature this patch,
only current nightlies and upcoming 1.7 candidates)
Keywords: relnote

Comment 316

15 years ago
Will the patch automatically go into the next (official) Firefox and Thunderbird
releases, too? If not, could someone of the developers make sure it does?

Comment 317

15 years ago
Downloaded the nightly build (4-13-2004). Installed and turned on the option. To
test it I minimized it and downloaded a ton of stuff overnight. This has al