Closed Bug 248423 Opened 20 years ago Closed 20 years ago

config.trim_on_minimize no longer works

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: robert, Assigned: benjamin)

References

Details

(Keywords: fixed-aviary1.0, regression)

Attachments

(1 obsolete file)

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.
Regression occurred in May 18 branch build. I'll have it narrowed down to the exact branch checkin and the corresponding trunk checkin soon.
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.
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.
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.
Assignee: firefox → bsmedberg
fixed-on-trunk, still need to land this on the branch
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: needed-aviary1.0
Flags: blocking-aviary1.0RC1?
(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?
Reopening until fixed on the branch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Could someone please clarify: did this make it into Firefox 0.9.2 ?
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. :-)
Flags: blocking-aviary1.0?
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Whiteboard: needed-aviary1.0
Attachment #152907 - Attachment is obsolete: true
Flags: blocking-aviary1.0- → blocking-aviary1.0?
No point in nominating a bug that's already been fixed.
Flags: blocking-aviary1.0?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: