248423 - config.trim_on_minimize no longer works

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Robert Parenton]

Setting the pref config.trim_on_minimize to false, which was introduced in Bug
76831, no longer works in Firefox, in both branch and trunk builds.  This used
to work, but stopped working sometime after the creation of the Aviary branch. 
Initially after the creation of the branch it worked on both branch and trunk
builds.

Expected behavior is that Mem Usage stays constant in Task Manager upon minimizing.

Actual behavior is that Mem Usage drops in Task Manager upon minimizing.

Comment 1

[Robert Parenton]

Regression occurred in May 18 branch build.  I'll have it narrowed down to the
exact branch checkin and the corresponding trunk checkin soon.

Comment 2

[Robert Parenton]

bsmedberg, your semi-single profile checkin broke the config.trim_on_minimize
code implemented in Bug 76831 comment #275.  For background on this pref and its
effect, see Bug 76831 comment #267, Bug 76831 comment #268, Bug 76831 comment
#281, and Bug 76831 comment #292.

Guilty checkin:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-17+18%3A26%3A00&maxdate=2004-05-17+18%3A26%3A00&cvsroot=%2Fcvsroot

This comment applies to the aviary branch only.  I'll post which checkin broke
it on the trunk and if that trunk checkin broke the pref in Seamonkey at some point.

Comment 3

[Ivan Todoroski]

I can confirm this bug is present in Firefox 0.9. Please bring trim_on_minimize
back, it solves one of the most annoying issues with Mozilla/Firefox, especially
on machines with plenty of RAM.

Comment 4

[Benjamin Smedberg]

This was caused because the new code created the hiddenwindow before the profile
was selected. The client code that reads the pref should really install a pref
observer, instead of relying on magic knowledge of when the hidden window is
going to appear.

Comment 5

[Benjamin Smedberg]

fixed-on-trunk, still need to land this on the branch

Comment 6

[Oakwine]

(In reply to comment #5)
> fixed-on-trunk, still need to land this on the branch

Could we get it back on the branch now?  And, should it be marked 'FIXED' if
only the trunk is fixed?

Comment 7

[Steffen Wilberg]

Reopening until fixed on the branch.

Comment 8

[Tony Tovar]

Could someone please clarify: did this make it into Firefox 0.9.2 ?

Comment 9

[Michael Lefevre]

Tony - No. The fix isn't yet on the Firefox branch.  0.9.2 wasn't taken from the
current branch code anyway - it was identical to 0.9.1 except for the single
security fix.

When it is actually fixed on the branch, that will be mentioned (in particular,
"fixed-aviary1.0" will be added).  In general, if it's not clear whether
something has happened, it means it hasn't. :-)

Comment 10

[Robert Parenton]

Attachment: Branch version of the patch checked in on the trunk

Comment 11

[Jesse Ruderman]

No point in nominating a bug that's already been fixed.