Option to Follow Site's Header Color

[maverick74]

Based on the comments on AMO's page:

Would be really cool that, instead of getting the color from the favicon, the addon could get the colors from the top of a webpage.

taking GitHub's example, VivaldiFox would color tabs and toolbars with black color. The effect of this, for those who might like it, would be the apparent merge between Firefox's UI and the Site's Look and feel.

As already mentioned we could have options to pick color from:

• FavIcon,
• Page's First Top-left pixel,
• Page's First Top-Center pixel, etc

I think the last option would be the most functional.

This would naturally have problems if we get to a site that has a header with a picture or a picture with degrade. But i think we can't do much in that cases and it would, at least, have one of picture's color.

[JanPokorny]

If I recall correctly, the FabTabs addon for Firefox (which used to have the same functionality, pre-Quantum) took screenshot of the top 200px of the page and used the median color (excluding white, black and other boring colors from consideration). That worked pretty well.

[maverick74]

@JanPokorny You have good memory!!! :) I completely forgot about FabTabs!!!

Still, if the color does not match "exactly" i'm not sure if it will work... :)

[JanPokorny]

Easiest way would probably be to group similar colors by hue and just pick the most common one. You want the saturation and brightness of the colored tabs to be normalised anyway, so the text is always readable.

[maverick74]

and would we be able to maintain that "continuity feeling" between firefox toolbars and site's header?

[nt1m]

Hi @maverick74 @JanPokorny

Thank you both for requesting this feature :) Can you test out this feature on the beta channel before I release it?

Go to the VivaldiFox preferences page, then change the "Fallback source".

[nt1m]

For info, it extracts the median color of the 50 top pixels of the page.

[maverick74]

Hi @nt1m
It kind of works...

It's not exactly how i dreamed about it. My idea (which does not mean it's a good idea or that it is doable) was to provide the idea of "continuity" between browser toolbars and webpage, (reason why i suggested from the top pixel)

But in this 2 examples that does not happen:
http://www.chriskrycho.com/2017/chrome-is-not-the-standard.html
https://cosmosmagazine.com/

but now that you mentioned the top 50pixels... instead of taking sample from top 50 pixels "vertically", why not the top-center 50 pixels "horizontally"?

It's not that it's bad the way it is!!! It's a lot better... i'm just shooting ideas that can (or not) make it even better =)

[JanPokorny]

@maverick74 I agree that choosing white in the first example isn't ideal -- much better would be choosing the blue color. That's why I proposed ignoring black, white and other boring colors.
It seems like the second example actually defines the theme-color in the source.
I don't think I understand what you mean by "continuity", could you provide an example?

@nt1m First of all, some bug reports:

1. When the page is scrolled down and refreshed, top 50px of the view is used instead of the "real top 50px". Try scrolling and refreshing here, for example: https://p2k.co/

2. Why does https://www.slevomat.cz/ have a blue tab? It doesn't seem like a dominant color at all...

Feedback: The new algorithm works really well for some pages (https://ksi.fi.muni.cz/ or https://imgur.com/), but it doesn't look very good with pages with white-ish background -- as there are many of those, they all tend to have the same color. I believe that choosing the accent color of the page instead in those cases will lead to tabs looking more colorful and pretty.

I propose discarding colors near white from the median calculation, which will lead to the accent color being chosen instead (e.g. blue here http://www.chriskrycho.com/ and yellow here https://fi.muni.cz/ ). (I remember FabTabs doing something similar to that, maybe discarding all colors with low saturation? Historical screenshot of FabTabs using the accent color instead of background color )
That won't work on all pages, sadly. E.g. https://www.mojebanka.cz/ has red accent color, but it doesn't occur in the top 50 pixels. (Maybe use a larger area, 200px perhaps?)

Anyways, thanks for implementing this feature! I'm sure that after some polishing, it will look as good as FabTabs once did.

[maverick74]

@JanPokorny
The idea is that it should feel like the tabs&toolbars where actually part of the webpage. In another words, by "continuity" i mean having the same color that's present on site's top.

examples:
https://planet.kde.org
https://www.phoronix.com

in the case of:
http://www.chriskrycho.com/2017/chrome-is-not-the-standard.html

in my ideia the tabs/toolbars color should have been the darkblue present on the site's top line

[nt1m]

@maverick74 @JanPokorny Thank you both for testing!

But in this 2 examples that does not happen:

One way to solve this is to use the top 2px or so, to avoid white being the dominant color.

but now that you mentioned the top 50pixels... instead of taking sample from top 50 pixels "vertically", why not the top-center 50 pixels "horizontally"?

This wouldn't solve the problem you've pointed out unfortunately, since white would still stay dominant.

That's why I proposed ignoring black, white and other boring colors.

The algorithm for page icons ignores those colors. For this mode, I've noticed ignoring shades of grey isn't very good for "continuity". For example, YouTube would select red instead of white, which would not make the header background match the chosen color. I agree however that it would make the chosen colors less boring though.

I think this is really up to the user's opinion here: for https://www.mojebanka.cz, I would guess @JanPokorny would prefer red as it's more colorful, but @maverick74 would prefer white to make the user interface match the page header background for "continuity". I guess the solution here would be allow configuring this using two separate modes.

When the page is scrolled down and refreshed, top 50px of the view is used instead of the "real top 50px". Try scrolling and refreshing here, for example: https://p2k.co/

This is because the API I use (tabs.captureVisibleTab()) captures screenshots of the scrolled area. There's another ctx.drawWindow() API that would fix this, but it requires injecting a content script, which isn't great for performance, and doesn't work on AMO or internal Firefox pages. I'm not sure what you would prefer here, but I think having it work on all sites without slowing down the browser is the best choice despite having that scroll issue :)

Why does https://www.slevomat.cz/ have a blue tab? It doesn't seem like a dominant color at all...

I think this is because I resize down screenshots to have a maximum width of 256 for performance. I'll consider increasing this max-width since it was originally chosen for icons (see issue #39)

Thanks for all the feedback! I'll go ahead with two separate modes: one that takes the 2 first pixels of the page, while keeping "boring" colors (continuity) and another mode that takes the 50 first pixels while ignoring "boring" colors (FabTabs style).

In case you're interested in checking the algorithm:

• findColor choses the right parameters for the color extraction: https://github.com/nt1m/vivaldi-fox/blob/master/background/color-utils.js#L103
• getColorFromImage does the actual extraction: https://github.com/nt1m/vivaldi-fox/blob/master/background/color-utils.js#L15

[JanPokorny]

@nt1m You're right that this is just a matter of preference, whether to prefer the background color or the accent color. (I have noticed that most pages setting the theme-color use the accent color, though.)

Ad the scrolling issue: the tab color is recomputed on each reload? (Reloading or pressing "back" keeps the scrolled position.) Wouldn't computing (and caching) the color for each domain only during the first load help? (Obligatory "FabTabs did it that way".)

I can see some issues with that:

• different pages on the same domain can have a very different design (this doesn't happen very often, only example I can think of are subreddits on reddit -- reddit sets the theme-color, however)
• some pages show an ugly and different colored "cookie disclaimer" at the top, which could confuse the color picker.

I think that rethinking when the color is computed and when the cached color is used could solve more problems (#63, #64, #65 all seem related) and furthermore it wouldn't matter that much if the color-computing algorithm was a little slower.

[maverick74]

I guess the solution here would be allow configuring this using two separate modes.

Well, i agree with the proposed solution ;)

[nt1m]

@maverick74 @JanPokorny Alright, I've uploaded beta 2: https://addons.mozilla.org/en-US/firefox/addon/vivaldifox/versions/beta

Please let me know how well that works, and what configuration you've picked (I've also added a setting to disable meta tag color extraction). Thanks for the feedback!

The mode that ignores boring colors doesn't work as well as I want to (the ideal would be a mix of ignoring and not ignoring), but it now works exactly like FabTabs: it takes the 200px top pixels (works better than 50 when ignoring boring colors), then extracts the median color.

As for the "continuity" mode, it works quite well and I am quite satisfied with the result. It seems to work even better when disabling meta tag extraction :)

@JanPokorny Caching is very hard to get right in all situations. There's some kind of tab-based caching done atm, and some update filtering done as well (to avoid flashing the color too much), and it doesn't work perfectly as you point out with the other issues. I agree it could be improved to do some smart domain/url caching as well, but too much caching (=memory usage) can slow down the add-on too.

[JanPokorny]

@nt1m The new accent color choosing algorithm doesn't seem to work. For https://www.mojebanka.cz/, it chooses light pink, https://fi.muni.cz/ gets white (even when disabling the theme-color preference). Even a page with a large red banner got white: https://www.csfd.cz/. I suspect it might be something with the way you resize the screenshot. Also, for the boring-color algorithm, I suggest converting the color representation to HSV and discarding all colors with low saturation (<10%, perhaps) -- this way, white or gray gets discarded even with a slight color tint.

[JanPokorny]

@nt1m Also, you say that you take the median color. Have you tried taking the most common color instead? (I suggest by converting to HSV and then counting colors by hue in "buckets" 0-10, 10-20... while remembering the average color for each bucket. Then take the average color of the largest bucket.)

[maverick74]

@nt1m
Well, i'm having better results with the Use theme-color meta tag when available on :)

when its able to get the color it works like a charm. Right like i dreamed about, however sometimes it can't get the color... no clue why. After a refresh it gets it.

Exceptions found: http://www.sapo.pt - http://www.imdb.com - top colors do not match. Any clue why?

https://www.space.com/ - https://addons.mozilla.org/en-US/firefox/addon/vivaldifox/ - might worth checking out why it's not working

[JanPokorny]

@nt1m Just to illustrate my point with low saturation, Facebook uses this color for background, and it gets chosen instead of the dark blue-purple: hsl(216, 13%, 92%). The dark blue-purple is hsl(220, 46%, 48%). I have checked the saturation of many accent colors, and have never seen a saturation lower than 40%. I think that setting the threshold around 30% will work for most of the sites.

[nt1m]

@maverick74 It gets the color as soon as it can, that means the page might not be loaded when the color is extracted, and it ends up taking white. I'm currently blocked on an API that would allow me to do that properly. After that I'll be able to fix the issues @JanPokorny pointed out.

Thank you both for testing!

[JanPokorny]

@nt1m Thank you for your work on this addon! Is there a ticket opened with Mozilla for the API issue?

[nt1m]

@JanPokorny https://bugzilla.mozilla.org/show_bug.cgi?id=1427463

I'm planning to work on the bug, but I'll probably only get to it in 2 weeks. So it will probably land in Firefox around Firefox 59-60.

[maverick74]

@nt1m Hi, i was coming to suggest that GitLab is not well either, but since you already identified the problem there's no need for it anymore :).

Thank you so much for your work on this feature. I'll keep an eye on that bug report as well. Where this already works it looks pretty awesome, will be waiting for that fix.

Thank you a lot (@nt1m ) again.

[maverick74]

@nt1m i'm sorry for asking, but just out of curiosity, in the bug you mention that "allows matching the header color with the two first pixels of the page". Why do you need the first 2 pixels?

[nt1m]

@maverick74 Whoops, I meant the two top pixel rows of the page. It's already possible at the moment with tabs.captureVisibleTab(), but it doesn't let you wait for the page to load, so it sometimes it captures 2 white rows.

[maverick74]

@nt1m I still don't get it!!! LOLOL
I thought that if we would get the color of the first top pixel of the page center it would be enough to get that "continuity" effect. That's why i'm curious about the need for more. (don't take me wrong, it's really just curiosity about "what i'm not thinking about" :p )

[JanPokorny]

@maverick74 It doesn't really matter which you take -- taking two full rows just makes the result better on pages with irregular top graphics.
The problem isn't with WHICH pixels to take, rather than WHEN to snap them. The current implementation is buggy, because sometimes the screenshot is taken before the page is fully loaded. I understand that @nt1m wants to implement the needed API to Firefox, so this issue can be resolved only after Firefox itself is patched.

[JanPokorny]

@nt1m With "accent color" mode, a seemingly random (but page-deterministic) color is assigned to black-and-white pages ( 1, 2, 3 ).

Is the random color intentional, or is it just a bug of the color-extraction algorithm? I also noticed that it happens even on pages that aren't completely B&W, like random pages on Wikipedia. (Wikipedia has blue links in the header.)

Also, it turns out long PDFs get recolored every time new pages get loaded, so the tab color changes randomly during scrolling on B&W PDFs. Try scrolling around here: https://eloquentjavascript.net/Eloquent_JavaScript.pdf

[nt1m]

@JanPokorny Due to the way Firefox renders text, black text is not always black. If you take a screenshot and zoom in the black-and-white, you'll see the text edges are not exactly black.

As for wikipedia, yes, once the algorithm detects a color different than shades of gray (boring colors), it immediately strips out boring colors from the list.

The continuity mode is currently the mode that works best. Unfortunately for the accent color mode, it's hard to have a perfect algorithm, sometimes you do want the boring colors (eg. white on Wikipedia), most of the time you don't want them... I'm thinking the page icon might be a better choice if you want non-boring colors.

[JanPokorny]

@nt1m Oh, that makes sense, I suspected that it has to do something with anti-aliasing. I'm sad that the accent color mode doesn't work as intended -- I wouldn't really mind if it chose the blue link color for Wikipedia, but there are two bigger problems that arose while using it for a little while:

1. Pages with too small accent-colored visual elements get somehow washed-out color (mojebanka.cz) -- probably from the resizing
2. Pages get often recolored while mid-scroll, making the color unpredictable (yeah, the API, I know...)

When (and if) the API gets fixed, I suggest trying out https://jariz.github.io/vibrant.js/ for the color selection. It looks it is able to extract even small amounts of accent color (e.g. the cat's eyes). Compare with the same cat image with Color-Thief.

[nt1m]

@JanPokorny I suspect mojebanka.cz is due to the slideshow images on the page. (Since the accent color mode takes the 200px top pixels of the page).

Thanks for showing me vibrant.js! It looks interesting, but I'd have to do some performance tests first (this is the main reason I prefer my own little algorithm vs a big library). I might consider tweaking the algorithm according to what vibrant.js does.

[JanPokorny]

@nt1m The new version of Vibrant.js has WebWorker support, does that help the performance? (https://github.com/akfish/node-vibrant) I think that using caching, a potentially single-per-domain operation wouldn't hurt the performance much. (Only downside would be that it could catch a wrong color on an initial load -- e.g. a cookie disclaimer -- that would introduce a need for "Recolor this tab" context menu button. Is such button possible with the current API?)

Ad mojebanka.cz:
Zooming in to 110% and reloading makes the tab darker red, 120% makes it the correct color. I blocked the slider using uBlock and nothing changed.

[maverick74]

@nt1m How's the work on the API (1427463)?
I don't understand it's state? Is it accepted in FF59 already?

[nt1m]

@maverick74 The API is now in Firefox Beta 59. I just haven't got time to work on VivaldiFox lately. Hopefully next week I'll be able to.

[maverick74]

@nt1m Great News Tim

(No need to rush! As always, Real Life gets in the middle - I know what that is...)

Thank you :D !!!

[maverick74]

@nt1m FF59 is almost here. Any ETA for this detail?

[nt1m]

@maverick74 I've got lots of things going on at the moment unfortunately :/ I'll try to look at it in April during my break.

[maverick74]

@nt1m No problem... was just asking to have an idea. This way i'll turn off my thinking of this issue until april :)
hope it's nothing "too" serious (just too much work...)

[nt1m]

Sorry for pushing this again, I've just been super busy these days.

I'm planning to have this for version 3. I put June as deadline for myself, but I might be able to finish before.

[JanPokorny]

@nt1m No need to rush, I actually got used to the favicon color algorithm and it works pretty neatly most of the time. The only thing that bothers me is #63 😄

[maverick74]

@nt1m funny, i was thinking about leaving a reply here today.
While it's something i'm very anxious to get, i understand that sometimes its not in our hands... real life is triky and there are other things - important ones - that must be put first.

So, take your time. We'll wait!!!

But please, when there are news leave a note here.

I'll keep an eye in this bug :)

[maverick74]

Off-topic: @nt1m don't know if you're aware or if it applies but i think vivaldi-fox could have great chances here: https://www.extensionschallenge.com/

[maverick74]

@nt1m Great to see this is on the "fix" path =D

[nt1m]

Hey @maverick74 @JanPokorny,

Thanks for your patience :)
I've made some improvements in the latest beta: https://github.com/nt1m/vivaldi-fox/releases/tag/v3.0b1

Please let me know how well it works :)

[maverick74]

Hi @nt1m :)

I think it's working great now (after i explored options more carefully)!!!

Will see how it behaves during the day =D

[maverick74]

Two small suggestions/details (IF they're possible):

1. On the Frame section (on advanced configurations) there's "Background", "Text" and "Apply page colors". Is there a way to (automatically) get "OS's native theme" on the frame?
   For example: i'm on Linux with a dark theme set for the entire DE (Breeze dark). I think it would look nice if we could get that theme loaded on the "background tabs" yet using vivaldifox for the selected tab.

2. If one loads, for example github, on the bottom of the page (e.g.: Option to Follow Site's Header Color #68 (comment) ) it will not set the color equal to the header's color but equal to where the page is loaded... isn't there a way to go around this and use the header's color?

[nt1m]

@maverick74 Thanks for testing !

For 1, there's unfortunately no way to provide this, the native color is not exposed to extensions.

For 2, there's no good way to do this, the only possible way involves an extra performance overhead and doesn't work on privileged pages unfortunately. Maybe this will change things: https://bugzilla.mozilla.org/show_bug.cgi?id=1429337

[maverick74]

@nt1m Well, i'm not particularly concerned about 1 or 2. They're just "details"!!!

The major feature is already accomplished with this release!!! I'm really happy with it!!! It seems to be working great!!!

Thank you for your work, Tim!!! :D It really looks awesome

[maverick74]

@nt1m in my opinion - from my use of it until now - i believe it is release-ready!

Did not find anything worth noting.

[maverick74]

@nt1m Will you this keep this bug open until bugzilla's1429337 is fixed? Or is there other reasons to keep it open?

[nt1m]

@maverick74 Sorry I completely forgot to provide updates about this.

Version 3.0 got released to the wide public with this feature: https://addons.mozilla.org/en-US/firefox/addon/vivaldifox/versions/

Thanks for all your testing!

[maverick74]

Hi @nt1m

i thought you were talking about https://bugzilla.mozilla.org/show_bug.cgi?id=1429337 and i missed it.

About v3.0, i noticed it :) Thank you :) It works great!!! :)

[maverick74]

@nt1m regarding bugzilla's 1429337 mentioned above: Do you have any patch sketched for this bug or is it too much to complicated (or time consuming)?

Should i create a new bug here to track it?

[nt1m]

@maverick74 I don't have time to work on it myself unfortunately, but I don't think it's too difficult to do.

[maverick74]

OK Tim, Thanks for clarifying it.
It's too much for my coding skills, so it's not possible for me either... which is a shame because, sometimes, it's an annoying detail and i would like to fix it...

maybe some other time... :)