Open johngruen opened 7 years ago
Would be cool, we could probably use an input type="Color" so long as the element display is somewhat customizable (i have no idea, but I assume we could hack it). Only issue i see is that we're currently declaring color vals in the SDK and WebExtensons bits of the experiment
Thanks, John. I hadn't had time yet to make it over here to post this as a request, was planning on doing so today - glad to see it made it over here already.
@johngruen to talk with the design team regarding more colours and the UX for this. Also looking at the different blue on blue tab highlight issues.
I'd also like more colors (and icons). While custom colors would be nice, just adding a few (4?) more would go a long way in the short term.
From the outset, consistently, I have wanted all containers to be colourless.
In the context of the location bar, that means black text (or whatever colour is used for the URL).
Similarly: icon-free · Issue #771 · mozilla/testpilot-containers
… blue on blue …
Also there are issues with the turquoise, green and purple presets.
With Mozilla's Compact Light, blue, turquoise and green overlines are barely distinguishable from the blue of the tabs:
With Compact Dark, legibility of purple text on the dark background is poor:
Over line is being dropped for this exact reason.
On Mon, 28 Aug 2017, 17:15 Graham Perrin notifications@github.com wrote:
… blue on blue …
Also there are issues with the turquoise, green and purple presets.
With Mozilla's Compact Light, blue, turquoise and green overlines are barely distinguishable from the blue of the tabs:
[image: 2017-08-29 00 52 23 compact light] https://user-images.githubusercontent.com/192271/29798786-25434f76-8c57-11e7-8dcf-927203d0ff5d.png
With Compact Dark, legibility of purple text on the dark background is poor:
[image: 2017-08-29 00 53 42 compact dark] https://user-images.githubusercontent.com/192271/29798823-5ef56312-8c57-11e7-94ae-7b13fece3d51.png
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/mozilla/testpilot-containers/issues/391#issuecomment-325517819, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUsLIQ445JGc7-QU6F_FeeXRO_-e2rhks5sc1gngaJpZM4MhDk3 .
Thanks
Over line is being dropped …
Sorry, I missed that. I see overline mentioned in 13 and 708 (" … Position of the url bar indicator will be resolved elsewhere. …"), and I imagined seeing underline in the past, but I don't know where to track the resolution.
If purple remains amongst the presets, then I guess that users of Compact Dark might simply avoid it.
… overline … underline … where to track …
Noted with thanks: Apply consistent underline to all firefox versions · Issue #779 · mozilla/testpilot-containers
… Just a little wasted space where previously there was an icon …
– and:
Here, for example:
I love a minimalist, functional toolbar. Essentials, left to right (ignoring unwanted ⓘ, book and mouse icons):
– with consistency of colour (black) for the two names, the address and everything else except the padlock icon.
The restraint everywhere except the padlock area increases the likelihood of that one most important area catching the eye if ever there is, for example, a red alert.
Snapped Padlocks 1.0.2 includes a faultless example of a red alert that's suitably restrained.
Hey all, dropping in to add that some of the current colors can be hard to differentiate for people with color blindness (friend was having trouble when I showed him containers). So either having more colors, custom colors, or colorless ways to differentiate containers would be really helpful on that front.
Repo folks: please, can you create an accessibility label and apply it to (at least) this issue? Thanks.
@mirdaki smart, thanks.
Off-topic from colours, part of what's appropriate is probably impossible with e.g. WebExtensions APIs, so I'll add what's required to Bugzilla@Mozilla – probably next week, when I'll have access to hardware that will allow a good demonstration of a use case.
I'm supporting this. Already opened a feature request for more colours: https://github.com/mozilla/multi-account-containers/issues/1101 but is unanswered
… it seems, that it was deleted
It's linked from the line before my previous comment.
This issue 391 is the earlier of the two.
… to Bugzilla@Mozilla – probably next week, …
Much later (!) than originally planned,
– @mirdaki there's yellow text on white background in the first two screenshots. More generally it'll be good for people with an eye (or ear) for accessibility to consider how things might look (or sound) if there's to be greater cohesion.
It's possible to manually edit a file – there's an example at https://github.com/mozilla/multi-account-containers/issues/984#issuecomment-348807006 – but (as indicated in the reply to my comment) it can be a bad idea, if not performed with care.
@grahamperrin I totally agree the yellow on white is a bad contrast. Even without being color blind I have trouble reading it from a distance. Granted, themes can change the white background so yellow could work sometimes.
In regards to placing the info on the left, I'm not sure how much it would do. I don't feel like most people associate the left side with security/privacy information, because I don't think most people pay attention to that (granted people using containers are probably more advanced and would have that association). Staying on the right may even help them stand out as they wouldn't be competing as heavily with other icons. I could be wrong of course. Doing some user testing is probably the only way to find out for sure.
Since I didn't saw it mentioned here, here's a CSS-only way to change container colors:
open about:profiles
, click on "open directory" for your active profiles root directory, open or create the chrome
folder, create userChrome.css
in it, with the content:
[data-identity-color="red"] {
--identity-tab-color: #000000 !important;
--identity-icon-color: #000000 !important;
}
Adjust #000000
to your liking. "red" can be any color you can set as container color, so you can overwrite different colors. Restart browser to see the changes.
Pro-Tip: Click the Firefox Menu, Select "Web Developer", Select "Browser Toolbox", Confirm the Dialog with OK. The Element-Picker (Top-Left) can select any Firefox Menu and reveal the underlying CSS that you can overwrite with userChrome.css
Source: https://www.reddit.com/r/unixporn/comments/78m6t1/oc_firefox_dark_theme/
@stoically While the CSS hack sort of works, it only changes the color on the container tab itself; it doesn't change the color in the Multi-Account Containers dialog box... It remains a hack, not a solution. Thanks anyway for sharing! (Note to my fellow colorblinds, the 8 pre-defined colors are named: "blue", "turquoise", "green", "yellow", "orange", "red", "pink", "purple".)
Is there a plan on implementing this?
+1 for at least more than 8 colours. It would be easy if we could just specify arbitrary colours, but e.g. in my use-case I have 16 different contexts I want to be able to run where each is a pair of related contexts, so ideally I'd setup my tabs with light purple/dark purple, light green/dark green, pink/red, light blue/dark blue, and so on. Hex codes, colour wheel, or even just supporting all of the 147 named colours, anything beats having to manually edit the extensions config files.
+1 for customizable colors, would be so very helpful
Before I read all the comments, I thought that fully customizable colors is overkill. Anyway somethings definitely should be done, at least adding much more colors. My personal issue is that I'm using dark theme everywhere where it's possible, and all the available colors are too bright. So, yup, it would nice feature to have.
https://github.com/mozilla/multi-account-containers/issues/391#issuecomment-325485077
From the outset, consistently, I have wanted all containers to be colourless.
In the context of the location bar, that means black text (or whatever colour is used for the URL).
– it's not only for ending colour variations, but it does meet my need.
I would also like to have more options. As I understand the concerns of colorblind people, I would suggest adding line-style.
with 10x colors and 3x styles I would have 30 options instead of 10 ... (I do not really use icon's as I can not see them when the tab is open).
Containers have a lot of potential but it is not prioritized at all, too bad..
It would be useful to just ADD more colors to the containers. i.e.: red, black and blue.
I'd love this extension to have the ability to set an arbitrary colour for a given tab, since it can already pick from the palette available and set the icon and name.
https://addons.mozilla.org/en-GB/firefox/addon/open-url-in-container/
That would make e.g. scripting it to log into specific AWS accounts in separate containers with a colour generated from hashing the profile name nice and simple.
Would be cool to finally see custom colors after 5 years of waiting instead of watching Mozilla VPN ads :)
I just noticed you've removed white color. I only tried to manage a container to check some settings and puuuf, the white color was gone... Like it wouldn't be bad enough for not giving us more colors but you also take away those we are used to. I don't know much of a coding but I can only imagine it must be really hard and time-consuming taken that this issue has been open for 5 years.
I was thinking the same as @BlooDCrescent - clearly Firefox is heading in the wrong direction, ramming VPN ads down my neck instead of basic functionality like custom colours - and removing them? Really?
5 years of people asking for more colors and nothing... How hard is it to open it up and let the user add custom colors? I mean for ** sake the colors are what the user looks at and identifies if a tab is in the container he is looking for. How can such a simple request take 5 years and no reply from devs? As it is now the user is essentially limited to only 8 containers as the colors are what a user can use to differentiate between the different containers on the tab bar. Maybe if the icons were shown on tabs on the tab bar the mix of color and icon would allow for more containers to be identified by the user at a glance. Either way for Mozilla to take more than 5 years to add functionality anyone would consider basic is appalling.
5 years of people asking for more colors and nothing... How hard is it to open it up and let the user add custom colors? I mean for ** sake the colors are what the user looks at and identifies if a tab is in the container he is looking for. How can such a simple request take 5 years and no reply from devs? As it is now the user is essentially limited to only 8 containers as the colors are what a user can use to differentiate between the different containers on the tab bar. Maybe if the icons were shown on tabs on the tab bar the mix of color and icon would allow for more containers to be identified by the user at a glance. Either way for Mozilla to take more than 5 years to add functionality anyone would consider basic is appalling.
I am in total agreement. It wasn't quite as bad when the whole tab was coloured, but now it's just a thin bar along the top, alongside the lack of colour choices, it is incredibly difficult to distinguish different tabs. I'm having to adjust my behaviour to have different containers in different windows because it's the only way I can easily seperate them. But I shouldn't have to.
It is a simple request and Mozilla wonder why they have a low share of the browser market, when stuff like this goes ignored.
This container system is genuinely BRILLIANT and INNOVATING and could capture people who are questioning their browser choices to sway them over to Firefox. Yet it's half baked with issues like this. The piss poor management is so confusing.
Either way for Mozilla to take more than 5 years to add functionality anyone would consider basic is appalling.
Applications aren't built like web pages, the CSS was generative initially and it caused slowdown in the browser; something which a lot more users would care about.
The browser would have to modify (https://bugzilla.mozilla.org/show_bug.cgi?id=1325057):
There's probably ~200 users who want this, who easily could modify userChrome.css as mentioned above. This repo has lots of examples of things Mozilla could also work on (that they haven't) but instead they're focusing improving privacy and security of millions of people.
The code is open source, patches are welcome etc!
PMJI : I'm a developer but not on this project. As a Firefox user, I want these MAC features like all others here. We cast our votes and hope that we get what we want - this is the way FOSS works. We don't always get what we want. Those of us who want these features are in the minority. Folks here need to deal with that reality.
I sometimes press for change too, especially when tickets are old and seemingly forgotten. (One sample is in another ticket on this same topic #1566.) But after expressing an opinion, concern, disappointment, even some indignation if feeling ignored, it's time to stand down.
@jonathanKingston provided some very helpful information about the details related to processing this request. He didn't need to take his time to do that. The downvotes on his comment are rude and I suggest removing them. I suspect the downvotes are there because those who added them are just disappointed that the feature hasn't been implemented, and they're seeing the notes here as an excuse, or "blah blah tech details blah blah". You've expressed your views about the feature. When you express your view on the quality of a comment, separate your opinions. There might be a very good comment on a feature that you don't support. Or a very bad comment on a feature that you do support. Jonathan's comment was detailed, well stated, well intended, and very helpful ... even if it means we ultimately might not get this feature for another 5 years or ever.
In summary: Please do separate your concerns. Blow off steam but do so productively. Show appreciation for developer interaction with your Free and Open Source Software. Don't demoralize developers into a state where they prefer not to interact. And if you feel that an issue requires more attention, as many of us do about this ticket, justify your position with the kind of detail that Jonathan provided. This applies to all GitHub projects and all FOSS everywhere.
Thanks for your time.
@jonathanKingston Perhaps another approach could be considered, with a different direction from the original implementation. Container tabs are treated as something special. Maybe that was taken too far. Maybe the UI elements should not be special.
When the identity is defined, the UI elements are wrapped in the data. I'm thinking it might be better to fire an event to get UI elements to override existing settings. This would be after the check for a valid icon/resource and after getting the color from the hard-coded map.
Tabs are dynamic. With every page refresh and other events we see the site Title injected into an attribute. Can we get access to all attributes of all DOM elements for tabs via the API? If so, might we be able to use an extension to determine which container a tab belongs to, so that we can set detail ourselves for text, borders, and back/fore colors. Same for the search/address bar that includes the icon SVG.
There seems to be a limited number of UI properties/attributes that are required to be set-able and get-able. A limited number of data properties need to be maintainable, like the table of containers. And the current identity for a tab needs to be get-able.
If we do have access to all required attributes (at the time when they are required), it seems we should be able to create extensions that replace the built-in functionality. Such an extension would need to duplicate the existing container settings functionality. It would require the ability to save a container definition without being forced to comply with the hard-coded list of colors and icons. It might need to disable and replace the Settings button for container tabs.
You see where I'm going with this. Abstract out the concepts of identity and UI updates, implement a default UI update, but fire an event for overrides before rendering. Am I missing anything?
I have never created a FireFox extension but I'm technically able to do so if you confirm our ability to do this all with an extension and no one else steps up.
Thanks.
@TonyGravagno You're saying nonsense and uselessly polluting the conversation trying to blindly defend the devs. While he's providing actually insightful and relevant information to the thread, the reason @jonathanKingston is downvoted is simply because his message is dishonest, arrogant and indifferent to a big chunk of the community.
First, saying
There's probably ~200 users who want this
is a blatant lie as can be clearly verified from the reactions on the first message in the thread. 117 upvotes as of today, and let's not forget people who commented here without upvoting, and the countless other duplicate issues (#1566 #1965 #2228 just to name a few) which have a lot of upvotes themselves and almost no overlap. So there are clearly more than 200 users who interacted in here about this issue. Which as any open source dev knows means that the actual total number of people who would want this feature is at least an order of magnitude higher.
To put it another way, this issue is literally the 8th most upvoted open issue for this project.
This should clearly be a priority feature if user demand was actually taken into account.
Lastly, @jonathanKingston is dismissing the issue claiming that people could use userChrome.css
when he knows that the vast majority of Firefox users aren't even aware of it. But most of all, it can only be used to override the current 8 colors available, you simply cannot add more colors which is the fundamental problem all those issue reports come from (even if the OP doesn't clearly states it).
Please consider this feature.
By the way @dannycolin (or @johngruen but he doesn't seem to be active anymore) could you please change the title of the issue to "Add ability to set custom colors/Add more colors" ? Since you're closing all related issues even if the OP never explicitly deals with having more (than the current 8) colors.
This would greatly add visibility and clarity.
This issue comes from Discourse: