In the Reading List sidebar, we want items to display a thumbnail and favicon to the left of the title/url. The mockup in bug 1120007 has the favicon displaying in the bottom right corner of the thumbnail block, which is 64x40 pixels.
Open question: Currently, the thumbnail service captures and stores thumbnails with a size of around 1/3 of the main screen. Which means we'll be downscaling potentially hundreds of thumbnails in the Reading List. Will this scale performance-wise, or do we need the thumbnail service to store pre-downscaled copies?

Oh, to note: The thumbnail service may merely be a fallback. The thumbnail may come from the synced list data, although that likely still means we'll need to capture it when we add it to the list.
Also, screen captures of the page may not be the best option, especially given the small size. There are various standards for defining summary metadata for a page (although OpenGraph seems to be the prevailing one), that include a representative/useful image.

(In reply to Bryan Clark (Firefox PM) [:clarkbw] from comment #2)
> michael is going to create a spec for what kind of information to grab from
> the page that'll probably pull from the opengraph data set.
Any update on this? (I'm starting to get blocked on waiting on these types of details)

rnewman: not sure if you're the right person to ask, but does mobile already have a plan (or code!) wrt comment 4? Presumably we'll want to have shared code for fetching the summary and article image...

Yea, we have some code. Three components that do this actually, Social API and ReaderMode both do this, and we have PageThumbs too. If Mobile also has its own thing, that's four ways of doing it inconsistently (and somewhat wastefully).
This is where a spec comes in handy :) I'm happy to just write up a spec myself, but comment 2 said Michael was already on it.

We have thumbnailing on Android, but that's probably not the same thing as "give me a picture to represent this article". I doubt there's anything to reuse there.
Bug 959297 added the excerpting, which is JS code that's now in toolkit:
toolkit/components/reader/content/Readability.js
-- see _getExcerpt.

(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #14)
> Are we dropping "thumbnails" from v1?
The thumbnails are key piece of the experience. If you feel this work is going to block us from making 38 we can discuss that.

(In reply to Bryan Clark (Firefox PM) [:clarkbw] from comment #15)
> If you feel this work is going to block us from making 38 we can discuss that.
I don't know offhand, dolske would have a better sense. We can discuss it next week.

Leaving on the P1 list as it's important UX, but still need to understand the engineering risk as to if this is feasible in time. Fallback would be to just show the logo placeholder ala http://cl.ly/image/1b1F0e3H2B3c (as we would do when the page doesn't have any preview image anyway).

(In reply to Justin Dolske [:Dolske] from comment #29)
> Comment on attachment 8580357[details][diff][review]
> Patch for check-in
>
> Review of attachment 8580357[details][diff][review]:
> -----------------------------------------------------------------
>
> ::: browser/components/readinglist/sidebar.js
> @@ +141,5 @@
> > itemNode.querySelector(".item-domain").textContent = item.domain;
> > + if (item.preview) {
> > + itemNode.querySelector(".item-thumb-container").style.backgroundImage =
> > + "url(" + item.preview + ")";
> > + }
>
> Tiny driveby:
>
> Can an item be updated to _remove_ a preview image? If so we'd need an
> |else| here to ensure any previously-set image is removed.
>
> But seems like that isn't super useful, and at worst is a temporary glitch
> (eg restarting the browser would fix it).
This is something simple that we could fix by removing the inline style if the value is not truthy.
> ::: browser/themes/shared/readinglist/sidebar.inc.css
> @@ +50,5 @@
> > border: 1px solid white;
> > box-shadow: 0px 1px 2px rgba(0,0,0,.35);
> > margin: 5px;
> > + background-color: #fff;
> > + background-size: contain;
>
> Hmm, should this be |cover|?
>
> I think the desired UX here is that it's more important to show the
> thumbnails at a consistent size, versus showing the whole EG, we don't want
> to letterbox the top or sizes of images with differing aspect ratios, but
> instead scale enough to fill the thumbnail region and crop any excess.
We can't use `cover` here. Florian and I looked at it and it is not working as the MDN docs on background-size:cover may lead people to believe. With cover, many thumbnails will simply be the top corner of the large image. Unless there is something funky about using `cover` that we don't know about and some other CSS property has to be enabled to get it to work, unlike `contain`.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #30)
> > Hmm, should this be |cover|?
> >
> > I think the desired UX here is that it's more important to show the
> > thumbnails at a consistent size, versus showing the whole EG, we don't want
> > to letterbox the top or sizes of images with differing aspect ratios, but
> > instead scale enough to fill the thumbnail region and crop any excess.
>
> We can't use `cover` here. Florian and I looked at it and it is not working
> as the MDN docs on background-size:cover may lead people to believe. With
> cover, many thumbnails will simply be the top corner of the large image.
> Unless there is something funky about using `cover` that we don't know about
> and some other CSS property has to be enabled to get it to work, unlike
> `contain`.
Actually, I think I was wrong here. I think we just needed to tweak background-origin. I'll try it out when my build finishes.