Closed Bug 1186011 Opened 9 years ago Closed 5 years ago

Make PageThumbs.jsm aware of multiple consumers and types

Categories

(Firefox :: New Tab Page, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox42 --- affected

People

(Reporter: oyiptong, Unassigned)

References

Details

PageThumbs is currently only built to expect one type of screenshot.
We are implementing another kind of 'thumb': a manifest icon.

We are thinking of implementing this by hooking into BackgroundPageThumbs / backgroundPageThumbsContent.

That said, current consumers of PageThumbs (TabGroup, CtrlTab) expect screenshots to be returned.

https://dxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/sites.js#237

https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser-ctrlTab.js#42

https://dxr.mozilla.org/mozilla-central/source/browser/components/tabview/tabitems.js#156

This bug is to track the work to augment PageThumbs to store both manifests and thumbnails and to provide an interface that will allow the retrieval of either via a parameter in the getThumbnailURL function.

The current thinking is to make the change have minimal impact on current consumers, with the default behavior to return a thumbnail.

When a parameter is supplied, the function will optionally return a manifest icon if available.
Assignee: nobody → oyiptong
No longer depends on: dynamic-tiles-v1
Depends on: 1186144
No longer blocks: 1187027
After having a conversation with ttaubert, here's the plan:

1. Make PageThumbs accept a 'scope' parameter
2. The default scope parameter value will be 'screenshot'
3. A new optional parameter will be 'icon'
4. An icon scope has additional parameters, of size, i.e. width and height

There is a little more thought about this API needed. Paraphrasing ttaubert:

> The storage could even accept multiple
> scopes and return an image for the first scope that has an asset for the
> given URL. Or you'd implement that kind of fallback only for
> about:newtab, guess we should pick what's nicer/simpler.

The fallback mechanism is as follows:

When the API is invoked with an icon scope, it will try and fetch the icon from storage and if that doesn't work, it returns the thumbnail.

The alternative that ttaubert proposes is for the interface to accept a list of scopes, such that dictates the fallback order.

I favor ttaubert's suggestion.
Status: NEW → ASSIGNED
Blocks: 1187027
No longer depends on: 1186144
No longer blocks: 1187027
Depends on: 1187027
Assignee: oyiptong → nobody
Status: ASSIGNED → NEW

No longer relevant...

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.