show a thumbnail of the bookmarked page in the organizer's properties pane

NEW
Unassigned

Status

()

Firefox
Bookmarks & History
10 years ago
6 months ago

People

(Reporter: dietrich, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
blocking-firefox3.5 -
wanted-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [places-ui], URL)

Attachments

(4 attachments, 8 obsolete attachments)

90.11 KB, image/png
Details
11.47 KB, patch
Details | Diff | Splinter Review
110.08 KB, image/png
Details
8.16 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

10 years ago
see the bug URL for mockups and notes.
Assignee: nobody → swon
Status: NEW → ASSIGNED

Updated

10 years ago
Blocks: 387751
Target Milestone: --- → Firefox 3 M8
Whiteboard: [swag:2d]
Whiteboard: [swag:2d] → [swag:2d][places-ui]
Different cases where a bookmark is created
1. "Bookmark This Page"
  -> Thumbnail should be created when the bookmark is created.
2. "Bookmark This Tab"
  -> Thumbnail should be created when the bookmark is created.
3. "New Bookmark"
  -> Thumbnail should be created the next time the bookmark is visited.
4. Drag and Drop
  -> Thumbnail should be created when the bookmark is created.
5. "Bookmark All Tabs"
  -> Thumbnail should be created when the bookmarks are created.

Those are the cases I can think of. Please correct me if I forgot or misunderstood something.

Should the thumbnails be updated after being created, and if so how often?
Whiteboard: [swag:2d][places-ui] → [places-ui]
Created attachment 276144 [details]
Screenshot from wip
steve, curious, for your patch, are you storing the screen shot as a data urls (as string annotations)

also, when going from canvas to a data url, we might want to be careful about the encoding and color depth we choose, to save space.
I am just saving it as a file and loading it for now. That is probably.. not what we want to do though. 

> Those are the cases I can think of.

in addition to dnd, there is also cut/copy and paste creation of bookmarks.
Created attachment 276194 [details] [diff] [review]
WIP

I attached parts of the WIP.
I couldn't attach the whole thing, since it was depending on the patch also from bug#387749.
But createThumbnail, saveThumbnail, and loadThumbnail are the three main functions that I was using.

Saving to file probably isn't the way we want to do this. And the path to the thumbnail is also hard coded in the attachment. So that should be changed also.
Out of curiosity, what size are we setting the content area to before rendering the screen shot, and what resolution are we downsizing the screen shot to?
It's being drawn and scaled in one show, to a 320x200 canvas.

PNG may or may not be the best output format for this... JPEG would probably result in a smaller file size. The downside is that the already-fuzzy images might look a bit fizzier, which may or may not be an issue at this size.
michael might have some good ideas about what what encoding to use (from his work on Reveal)
Wouldn't 320x240 be a better aspect ratio?  Do Web designers still usually target 1024x768?

As we scale down I think we will start to lose the benefits of PNG because the easily compressed areas also get smaller.
Hrm, actua(In reply to comment #10)
> Wouldn't 320x240 be a better aspect ratio?

Hrm, now that you mention it, the WIP code should be fixed to preserve the current window's aspect ratio when it's drawn into the canvas.
>the WIP code should be fixed to preserve the current window's aspect ratio

Then all of the thumbnails would end up being at different aspect ratios, which won't later allow us to tile them next to each other in a spiffy thumbnail view :)  Could we render the canvas to a hidden iframe at 1024x768 before we take the screen shot?

In the cases where we need to send post data again, we could just crop 1024x768 from the current canvas and then resize that (with possible white space if it is too small).
Assignee: stevewon → nobody
Status: ASSIGNED → NEW
taking over from where steve left off, assuming mano and dietrich don't object.
Assignee: nobody → sspitzer
Flags: blocking-firefox3?
faaborg, can you confirm that the new look is supposed to be:

http://people.mozilla.com/~faaborg/files/granParadisoUI/placesOrganizer_i5WindowLayout.png

and not http://wiki.mozilla.org/Places:User_Interface/Organizer/i1

I'll attach an updated patch that uses the annotation service to store the data url.
Status: NEW → ASSIGNED
>faaborg, can you confirm that the new look is supposed to be

Yes, iteration 5 (i5) is the latest mockup.
Created attachment 277484 [details] [diff] [review]
updated wip patch
Attachment #276144 - Attachment is obsolete: true
Attachment #276194 - Attachment is obsolete: true
Created attachment 277551 [details] [diff] [review]
use "load" event instead of a progress listener
Attachment #277484 - Attachment is obsolete: true
Created attachment 277590 [details] [diff] [review]
updated patch
Attachment #277551 - Attachment is obsolete: true
Created attachment 277641 [details] [diff] [review]
updated patch
Attachment #277590 - Attachment is obsolete: true
Created attachment 277642 [details]
screen shot
Created attachment 277778 [details] [diff] [review]
updated patch
Attachment #277641 - Attachment is obsolete: true
Created attachment 277787 [details] [diff] [review]
update patch (contains mano's wip patch for bug #387749)
Attachment #277778 - Attachment is obsolete: true
Created attachment 277992 [details] [diff] [review]
updated patch, removed todo comment (I've logged bug #393482)
Attachment #277787 - Attachment is obsolete: true
problems with this current patch:

1) I scale the web page into 320 x 240, instead of trying to preserve the original ratio.  alex has some ideas of how best to preserve the original ratio.

2) when displaying the thumbail, I scale back from 320 x 240 to the size of the canvas element.  ideally, the canvas tag will also be 4:3, ideally 320 x 240

3) when resizing the preview pane, which can happen if you move the spliter or or toggle the tags drop down.  we should preserve the 4:3 ratio of the thumbnail, isntead of stretching it.

alex, can you elaborate on your idea of how to preserve the original ratio?
Blocks: 393514
>alex, can you elaborate on your idea of how to preserve the original ratio?

When we are showing a lot of thumbnails together at the same time (perhaps in the future) it would probably be good if they weren't at a variety of different aspect ratios, and different levels of zoom.

Fixing the aspect ratio is pretty straightforward: we figure out which is larger, height or width, and then take 4:3 from the upper left corner (do we need to do upper right for some localizations?)

Fixing zoom is a little more complicated: we would need to crop out the upper left 1024x748, and then scale that down to 320x240.  If that isn't available, fall back to the upper 640x480, etc.
Created attachment 278618 [details]
scaling and cropping example

I think there are two different issues here...

The simple issue is to avoid distorting the screenshot when it's scaled down from the original size and displayed. This is a fairly trivial, quantitative process. I think the feature could land with only this issue fixed, although it would lack a certain degree of polish.

The complex issue is to make all thumbnails look consistent. For example, bookmarking a page when the browser window is tall-and-narrow [Y >> X] would currently result in a different icon than when the browser window is short-and-wide [X >> Y], as the <canvas> .drawImage just grabs from the existing window. One thumbnail might end up as a 50x240 image, and the other might be 320x75. You can crop the original screenshot so that the thumbnail is always a full 320x240, although now you have to make qualitative judgements as to a "good way" to crop the image. [As a contrived example, if you just cropped the edges of the screenshot until it was 4:3, the first things to go would be the site's header/footer or sidebars... Those are generally strong visual clues about the site's identity, so there would be grumbling about the thumbnail's usefulness.]

Alex's comment made me think about maybe scaling the screen by a limited factor (to preserve legibility) and then cropping to the upper-left 320x240. It's more of a "teaser" than a full-fidelity "thumbnail". This works nicely for the attached example with Slashdot, although I'm sure it's not hard to find counter-examples.

It might be worth modifying a Tabspose extension (or something like https://addons.mozilla.org/en-US/firefox/addon/2134) to use whatever scaling/cropping algorithm we want to use for bookmarks, in order to rapidly tune the algorithm to maximize its usefulness.
I find 320x240 rather unappealing using a wide-screen monitor. Even with a 4:3 monitor, you don't actually reach that ratio on a page unless you're in full-screen mode.
I'd prefer 320x220, which is 16:11 and right between 4:3 and 16:10.
moving to m9, but mano might be including some of this with bug #387749
Target Milestone: Firefox 3 M8 → Firefox 3 M9
If it came down to it we'd ship without this, but it's really-really-really want. Really.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [places-ui] → [places-ui][wanted-firefox3]
mconnor and I were discussing this over irc, and he was wondering why we should take a snapshot instead of generating the snapshot when we need it (for preview).

a few reasons:

1)  snap shot doesn't require auth (as we could take the snapshot once you're logged in)
2)  showing the user what they last saw vs. something else.
3)  if we implement a "thumbnail view" of bookmarks, we would get better user experience if we had the thumbnails, instead of going and generating them all.
4)  offline

note, this came up because we were discussing the impact that storing screen shots in places.sqlite would have on bugs like #332748
beltzner writes:

"I was talking with Alex and mconnor, and both were telling me that there's work going on to get the preview image in Places cached for quicker response. I think this is great, but we shouldn't block on it and the priority should be getting a live preview in there -- especially since pages change, and a live preview would be a little more useful -- and some sort of throbber or indicator as it was being generated. Just wanted to make sure that we weren't killing ourselves working on something when a simpler solution was available.

Of course, caching would be nice in order to speed up the render, but I don't think it's a P1."
In that case, I don't think canvas is the best solution. Maybe use an iframe with fullZoom = 0.x?
If we end up using an iframe, we might want to change the zoom variable and drop the properties section on the right for live mark items, and we've basically got ourselves an RSS reader :)
Since the full-page zoom is fairly new, do we know it's working well enough to use here? Does it handle plugins?

I suppose a live preview would be useful in some cases, but I'd tend to think a static thumbnail would be far more useful because it should be an instant preview... For example, consider a user who has bookmarked/tagged a bunch of "favorite images" (which may or may not be porn :-), and wants to locate a particular one. Waiting for dozens of pages to load and render their live previews would be a painful experience. It might also look like bad perf, depending on how obvious it was that the preview is being loaded live.
(In reply to comment #34)
> Since the full-page zoom is fairly new, do we know it's working well enough to
> use here? Does it handle plugins?

It depends on the plugin and the content, as far as I can tell. For example, youtube videos work quite well. And canvas doesn't support plugins at all.

> I suppose a live preview would be useful in some cases, but I'd tend to think a
> static thumbnail would be far more useful because it should be an instant
> preview... For example, consider a user who has bookmarked/tagged a bunch of
> "favorite images" (which may or may not be porn :-), and wants to locate a
> particular one. Waiting for dozens of pages to load and render their live
> previews would be a painful experience. It might also look like bad perf,
> depending on how obvious it was that the preview is being loaded live.

Instant previews have their advantages, but so have live previews. Anyways, /if/ the previews won't be stored (comment 31), then canvas won't be instant either.

Comment 36

10 years ago
(In reply to comment #35)
> (In reply to comment #34)
> > Since the full-page zoom is fairly new, do we know it's working well enough to
> > use here? Does it handle plugins?
> 
> It depends on the plugin and the content, as far as I can tell. For example,
> youtube videos work quite well. And canvas doesn't support plugins at all.

We should disable plugins either way. I wouldn't want a preview to play sound, which many flash sites tend to do without needing user interaction. If it was up to me, I'd go with canvas...

If you do go with an Iframe, how will you solve the problem of links on the webpage? I doubt we would want the Iframe to become a full-on browser ;-)
Hm, I see your points about latency, but the tradeoff is against the perf hit of caching all of these pages, especially if a user sails through them quickly as they visit.

What's going to be faster for the user?

As for using an iFrame, I think I'm with Ventnor; I wouldn't want that to be a LIVE preview of the site.
(Reporter)

Comment 38

10 years ago
Seth provided very good reasons for caching snapshots in comment #30. Live previews are subject to unpredictable conditions and behavior, as enumerated in many of the previous comments: latency, sound, authentication, etc.

> 
> What's going to be faster for the user?

Showing a single static image from a local cache (whether annotations, file system or whatever) should be faster than the network IO and page-rendering required for live preview. If it's not, then we need to address these shortcomings in our cache system.

Comment 39

10 years ago
(In reply to comment #24)
> alex, can you elaborate on your idea of how to preserve the original ratio?
> 

I have my own idea. Specify the width as 320, but calculate the height using the aspect ratio of the browser window during createThumbnail.

canvasheight = canvaswidth x (innerheight / innerwidth)

This should hopefully preserve the aspect ratio on any page.
>Specify the width as 320, but calculate the height using
>the aspect ratio of the browser window during createThumbnail

This will result in thumbnails having different heights, which may look bad when we are in a thumbnail view (Firefox 3+) and the thumbnails are all lined up next to each other.

Comment 41

10 years ago
(In reply to comment #40)
> >Specify the width as 320, but calculate the height using
> >the aspect ratio of the browser window during createThumbnail
> 
> This will result in thumbnails having different heights, which may look bad
> when we are in a thumbnail view (Firefox 3+) and the thumbnails are all lined
> up next to each other.
> 

But the image thumbnail view in Windows Explorer is like this anyway, isn't it?

Comment 42

10 years ago
(In reply to comment #41)
> But the image thumbnail view in Windows Explorer is like this anyway, isn't it?

Yes.  It encloses the thumbnail in a frame centering horizontally or vertically as needed, a trick for the eye that might work here too. 
moving out to m10
Target Milestone: Firefox 3 M9 → Firefox 3 M10

Updated

10 years ago
Depends on: 399280
Comment on attachment 277992 [details] [diff] [review]
updated patch, removed todo comment (I've logged bug #393482)

>+                <hbox id="preview" style="min-width: 60px; border: 1px solid;">
>+                  <html:canvas id="bookmark_thumbnail"/>
>+                </hbox>

>+  loadThumbnail: function PDP_loadThumbnail(aURISpec) {
>+    var canvas = document.getElementById("bookmark_thumbnail");
>+    var ctx = canvas.getContext("2d");
>+    ctx.clearRect(0, 0, canvas.width, canvas.height);
>+
>+    try {
>+      var uri = this._uri(aURISpec);
>+      var imageURL = this.annotations.getPageAnnotation(uri, PREVIEW_ANNO);
>+      var img = new Image();
>+      img.onload = function() {        
>+        ctx.save();
>+        ctx.scale(canvas.width/PREVIEW_WIDTH, canvas.height/PREVIEW_HEIGHT);
>+        ctx.drawImage(img, 0, 0);
>+        ctx.restore();
>+      }
>+      img.src = imageURL;
>+    }
>+    catch (ex) {
>+    }
>+  },

I think you should be using a xul:image here and just set the imageURL as its source.

Comment 45

10 years ago
So what are we going to do here?

Comment 46

10 years ago
Created attachment 288774 [details] [diff] [review]
Preserve aspect ratio

I've been trying to work on this myself so I really hope you don't mind, Seth. To solve this problem of aspect ratios why don't we just take the same approach as file managers take when they show image thumbnails? The image is scaled down to fit within constraints while keeping the same ratio, and centered in the preview area.

I've been using this and it works very well. I can't think of a better approach to take and I really, really would like to see this in Fx3...
Attachment #288774 - Flags: review?(sspitzer)
Comment on attachment 288774 [details] [diff] [review]
Preserve aspect ratio

>+  // Preview annotation ID
>+  PREVIEW_ANNO: "bookmarkProperties/preview",
>+  // Preview thumbnail width
>+  PREVIEW_WIDTH: 320,
>+  // Preview thumbnail height
>+  PREVIEW_HEIGHT: 240,

As stated in comment 27, I think this should be 320x220.

>+    try {
>+      var ctx = canvas.getContext("2d");
>+      ctx.scale(canvas.width/w, canvas.height/h);
>+      ctx.drawWindow(aWin, 0, 0, w, h, "rgb(0,0,0)");
>+      var dataURL = canvas.toDataURL("image/jpeg", "");
>+      this.annotations.setPageAnnotation(aURI, this.PREVIEW_ANNO, dataURL, 0, Ci.nsIAnnotationService.EXPIRE_WEEKS);
>+    } 
>+    catch (ex) {
>+      LOG("createThumbnail failed: " + ex);
>+    }

What are you catching here?

>-  _updateThumbnail: function PO__updateThumbnail() {
>+  _updateThumbnail: function PO__updateThumbnail(aURISpec) {
>     var bo = document.getElementById("previewBox").boxObject;
>     var width  = bo.width;
>     var height = bo.height;
> 
>     var canvas = document.getElementById("itemThumbnail");
>     var ctx = canvas.getContext('2d');
>+    try {
>+      var uri = IO.newURI(aURISpec);
>+      var imageURL = PlacesUtils.annotations.getPageAnnotation(uri, PlacesUtils.PREVIEW_ANNO);
>+      var img = new Image();
>+      img.onload = function() {        
>+        ctx.save();
>+        // center the image in the thumbnail
>+        if (img.width < PlacesUtils.PREVIEW_WIDTH)
>+          ctx.translate((PlacesUtils.PREVIEW_WIDTH - img.width) / 2, 0);
>+        if (img.height < PlacesUtils.PREVIEW_HEIGHT)
>+          ctx.translate(0, (PlacesUtils.PREVIEW_HEIGHT - img.height) / 2);
>+        ctx.scale(canvas.width/PlacesUtils.PREVIEW_WIDTH, canvas.height/PlacesUtils.PREVIEW_HEIGHT);
>+        ctx.drawImage(img, 0, 0);
>+        ctx.restore();
>+      }
>+      img.src = imageURL;
>+    }
>+    catch (ex) {
>+      var notAvailableText = canvas.getAttribute("notavailabletext");
>+      ctx.save();
>+      ctx.fillStyle = "-moz-Dialog";
>+      ctx.fillRect(0, 0, width, height);
>+      ctx.translate(width/2, height/2);
>+
>+      ctx.fillStyle = "GrayText";
>+      ctx.mozTextStyle = "12pt sans serif";
>+      var len = ctx.mozMeasureText(notAvailableText);
>+      ctx.translate(-len/2,0);
>+      ctx.mozDrawText(notAvailableText);
>+      ctx.restore();
>+    }

The preview should be a XUL image, and it's source should be |PlacesUtils.annotations.getPageAnnotation(uri, PlacesUtils.PREVIEW_ANNO);|.
> I really hope you don't mind, Seth.

not at all.

Note, I'm nervous about us using places.sqlite to store the preview image.

here's an alternative idea:

1) we don't store any value in places
2) to see if we a preview for a given uri, instead of:

var imageURL = PlacesUtils.annotations.getPageAnnotation(uri, PlacesUtils.PREVIEW_ANNO);

we take the uri, hash it to create a unique file name, and look for
<profile>/previews/<hash>.jpg

we will not need to base64 decode the image.

3) to store a preview, we do the same thing (use the file system), and when we write out the preview as a jpg, and skip the base64 encoding.

4) upon page expiration from places.sqlite, we should also check if <profile>/previews/<hash>.jpg exists, and if so, remove it.

this should prevent previews from causing performance problems with autocomplete (for example), by consuming too much of our sqlite cache.

additionally, since these are file urls, we will be able to leverage the browser's disk cache between sessions.  (note, I think data urls would have leveraged the browsers memory cache, but that's not cross session.)

note, I think we've had "too-many-files-in-a-single-folder-hurts-performance" problems (with the disk cache), so we might need to follow what the disk cache does there.
Assignee: sspitzer → ventnor.bugzilla
Status: ASSIGNED → NEW
additionally, we need to see what sort of impact this is going to have on Tp, Ts and Txul.

on page load, we're going to be checking if a uri is bookmarked (at the least), and if so, we'll be creating and writing a thumbnail out to disk
a different approach could be having a preview.sqlite, and using ATTACH DATABASE to unify queries with places. This way places.sqlite does not grow and does not have performance problems, while you can do vacuum and other ops on the separate preview.sqlite (or thumbs.sqlite since on Windows there is already thumbs.db)
This shouldn't actually have too much effect on your implementation decision, but just throwing the idea out there:

I'm a little worried that if we place thumbnails of all bookmarks in a folder, it becomes really easy for another user to open the folder, turn on thumbnail view or coverflow view, and keep browsing until they quickly find the secret they are looking for.  At least with the bookmarks organizer you can only view one thumbnail at a time, and bookmarks might have intentionally obfuscated names.  Until we implement private browsing mode, we have to consider the impact that certain implementation decisions could have on our users.
I don't think there's any security or privacy difference between storing thumbnails as files or in a SQL db. A thumbnail can be easily extracted from either source. if another user is able to browse your profile, they can also get at your bookmarks, history, and cache (and passwords, if you don't have a master password set), so it's already "game over".

Thumbnails do represent yet another privacy concern, but as long as they're removed when the bookmark is removed that seems sufficient. There are some edge cases [eg, a password protected "bland-domain.com" site which the thumbnail reveals to be porn.], but I'm not sure if they're common enough to worrying about. Perhaps a pref to disable thumbnail generation would be enough.

Bug 16489 covers protecting the whole profile with a password.
> I don't think there's any security or privacy difference between storing
> thumbnails as files or in a SQL db. 

until you don't do a secure delete from the disk (more rewrite of the same cluster) the image will be recoverable with common file recovery software... while in sqlite using the secure delete the area will be zero-filled, then written over by new data on request (will be in sqlite freelist).

the point is that there should be a limit on the number of items, since now the only limit on places is 20 000 entries, if you suppose to have (worst case) 1 visit per entry you will have 20 000 thumbs, 10KB per thumb will be about 100MB of images to store...

i think that places limit should be cut to a limit on the number of unique urls and a limit on the number of visits to each url. So with 2000 url and 20 visit per url you will end up with a maximum of 20 MB of thumbs and 40 000 entries.
Ok, you are both totally right about access to the slite database and about writing over data with random data.

But there's a difference between professional data recovery, writing code to access a database, and just opening a folder on the file system.  Unless it's totally encrypted it's game over in the totally logical sense, but I'm talking about practically.  Extracting information from a sqlite database would be harder than just loading the bookmarks organizer and looking for private information, so people would just do that to snoop on someone.  I'm specifically worried about us creating an even easier way for someone to visually scan all of a user's bookmarks (even though in every case it is "game over" in the technical sense).  If we want to store the thumbnails directly on the file system, then perhaps we should at least change the file extension.
(In reply to comment #53)

> until you don't do a secure delete from the disk (more rewrite of the same
> cluster) the image will be recoverable with common file recovery software...

I don't think that's relevant. We already dump plenty of stuff to disk (eg cache), and if we want to fix that problem it should be in a general way, and not with per-instance hacks.


(In reply to comment #54)

> Extracting information from a sqlite database would be
> harder than just loading the bookmarks organizer and looking for private
> information

Click, click, I just installed the SQL DB Image Viewer extension. Security through obscurity is rarely a worthwhile thing.
Comment on attachment 288774 [details] [diff] [review]
Preserve aspect ratio

michael, thanks for working on this.   the patch has probably bit rotted heavily since Mano's recent landing (including the removal of the preview pane).

clearing review request.
Attachment #288774 - Flags: review?(sspitzer) → review?
perhaps this could become an add-on, using nsINavBookmarkObserver to determine when to remove a screen shot from disk.
Attachment #288774 - Flags: review?

Comment 58

10 years ago
I don't think its a good idea to store the previews in places.sql
A little while ago I tried storing previews like this in places.sql and because of it Firefox would take forever to shutdown. I'm not sure if it was totally because of the images, but that probably played a large part. I'm not sure if saving as files in a folder or in a separate db would be better though. 

I'm currently working on a cover flow and thumbnail view extension for the bookmarks organizer for FF2 & FF3(The cover flow and preview creation is almost done in both) and went with saving previews as files in a folder, although instead of hashing the filenames I just encoded their names, just because it was quicker. Other than that I used pretty much the same as what was mentioned in comment #48. If there is a "too-many-files-in-a-single-folder-hurts-performance" problem, then maybe the files could be saved in a sub folder based on the site's domain? In FF3 it uses an nsINavBookmarkObserver like in #57 to remove/add and in FF2 it uses the bookmark transaction manager.

If you think this should be an add-on, I would be fine adding it to mine since it will already have preview creation code. I'm not sure what the performance issues would be involved with saving bookmarked pages or the extra size the images would take up, but for that reason alone it might be a decent idea to make it an extension.

Updated

10 years ago
Assignee: ventnor.bugzilla → nobody
(Reporter)

Updated

10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Flags: wanted-firefox3+
Whiteboard: [places-ui][wanted-firefox3] → [places-ui]
i still think that the best implementation would be:
- store into a separate thumbs.sqlite and attach it to places db connection (so it will cause no slowdown or vacuum problems on places)
- mantain thumbnails of bookmarks, and maybe of last X visited items (because if you have 5000 places and thumbs of 10KB you already end up with about 50MB of thumbs, so there should be some hard limit on the number of thumbs)
- expire thumbs on idle/close, with an expiration cap limit (to avoid heavy disk usage with large deletes)
(Reporter)

Updated

10 years ago
Target Milestone: Firefox 3 beta3 → ---
Could this be something for Firefox 3.1?

(In reply to comment #59)
> - store into a separate thumbs.sqlite and attach it to places db connection (so

Could this file be placed in the cache folder and not the profile folder then? Otherwise it unnecessary blows up the profile folder, which will be bad for e.g. portable profiles.
Flags: blocking-firefox3.1?

Updated

9 years ago
Flags: blocking-firefox3.1? → blocking-firefox3.1-

Updated

9 years ago
Depends on: 497543
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.