Open Bug 1337397 Opened 7 years ago Updated 7 months ago

Add mask-icon and average color support to favicons

Categories

(Toolkit :: Places, defect, P3)

defect

Tracking

()

Tracking Status
firefox54 --- affected

People

(Reporter: mak, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [fxsearch])

We want to properly support mask-icon favicons and store the average color for each icon payload.
The former could be stored as separate info, or just merged into the payload, TBD.
Color information should be returned through the API.
Depends on: 977177
Priority: P3 → P2
No longer blocks: PlacesHiresFavicons
Priority: P2 → P3
Blocks: 1647173
Blocks: 1706689

The potential concerns with mask-icon is that:

  • we should store the site provided color attribute along with the icon. Potentially not a big deal, though the site doesn't specify if that color should be used against light or dark, so we'd need some contrast calculation to return either this color, or white, or black, depending on the ui dark/light theme.
  • When using page-icon protocol, it just returns an image, thus we should manipulate the image content to replace the fill before returning it (adding a style that uses @media prefers-color-scheme may suffice). That means we may also need another #ref (apart from the already existing #size) to tell whether the theme is light or dark. We may alternatively do something like setDefaultIconURIPreferredSize, thus add a setDefaultIconURITheme and set it to dark or light when the theme changes, then icons would be served accordingly. If there isn't enough contrast with color, it looks like safari adds a white background, we may either do that or just try to use context-fill.
  • I think the problem with SVG was that context-fill would not work on Web provided SVGs. SVG 2 had some kind of support for it, but I don't know what's the state for that. Though since we have to rewrite the icon contents for the reasons above, we may also just replace fill value with context-fill and try if it works in chrome-prividged contexts...

So in the end I think it boils down to store color along with the icon (the database moz_icons table already has a color column for that, currently unused) and manipulate the icon on the way out.

See Also: → 1792046
Severity: normal → S3
Duplicate of this bug: 1801614
See Also: → 1801614
You need to log in before you can comment on or make changes to this bug.