Minimize disk space usage on Windows CE

RESOLVED FIXED in Firefox 3.7a1

Status

()

Firefox
General
P1
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Dolske, Assigned: Dolske)

Tracking

({meta})

Trunk
Firefox 3.7a1
ARM
Windows CE
Points:
---

Firefox Tracking Flags

(status1.9.2 final-fixed)

Details

(Whiteboard: [nv])

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
We're often tight on disk space on small devices, running low can cause problems like being unable to apply app updates. A few obvious targets:

* Reduce Places history to keep down the size of places.sqlite
* Reduce disk cache to a smaller size (and possibly relocate it?)
* Clear disk cache on exit if there is a pending software update
* Clear out any .sqlite-corrupt files on start/exit
* Maybe lower limits for cookies and form history
* Look at other profile files than can grow and how we might limit them.
(Assignee)

Comment 1

9 years ago
Created attachment 417418 [details] [diff] [review]
Patch v.1

This should be good enough... I didn't see any other prefs that would yield significant savings, nor any other files in my (desktop) profile that would be worth nuking (with the possible exception of the XPC/XUL.mfasl files, which are a combined 4.5MB on OS X).
Attachment #417418 - Flags: review?(vladimir)
Comment on attachment 417418 [details] [diff] [review]
Patch v.1

works for me.
Attachment #417418 - Flags: review?(vladimir)
Attachment #417418 - Flags: review+
Attachment #417418 - Flags: approval1.9.2+
(Assignee)

Comment 3

9 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/1ce17c92a928
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
(Assignee)

Comment 4

9 years ago
Pushed to 192: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7b527f308e84
status1.9.2: --- → final-fixed
I wonder if the check for a pending update should be done differently in the future since this approach likely adds around 40ms to every shutdown on the tegra. The 3.6b1 nsUpdateService.js took around 44ms in js_Execute on the current tegra image and I suspect that hasn't changed much.
we could do it in the fast start daemon when the device is idle
Comment on attachment 417418 [details] [diff] [review]
Patch v.1

>diff --git a/browser/components/nsBrowserGlue.js b/browser/components/nsBrowserGlue.js
>--- a/browser/components/nsBrowserGlue.js
>+++ b/browser/components/nsBrowserGlue.js
>@@ -311,16 +311,28 @@
> 
>     this._observerService
>         .notifyObservers(null, "browser-ui-startup-complete", "");
>   },
> 
>   // profile shutdown handler (contains profile cleanup routines)
>   _onProfileShutdown: function() 
>   {
>+#ifdef WINCE
>+    // If there's a pending update, clear cache to free up disk space.
>+    try {
>+      let um = Cc["@mozilla.org/updates/update-manager;1"].
>+               getService(Ci.nsIUpdateManager);
>+      if (um.activeUpdate && um.activeUpdate.state == "pending") {
>+        let cacheService = Cc["@mozilla.org/network/cache-service;1"].
>+                           getService(Ci.nsICacheService);
>+        cacheService.evictEntries(Ci.nsICache.STORE_ANYWHERE);
>+      }
>+    } catch (e) { }
>+#endif
This should also be ifdef'd MOZ_UPDATER since this component isn't available if that isn't set. I am also adding AC_DEFINE for MOZ_UPDATER in Bug 526333
(Assignee)

Updated

9 years ago
No longer blocks: 535520
Depends on: 535520

Comment 8

9 years ago
Instead of ifndef's I would have used ifdef's.
That makes the reading easier...
You need to log in before you can comment on or make changes to this bug.