Open gwynnarth opened 7 years ago
Yes, firefox can't get the favicons. I personally use Humble New Tab Page, which shows my bookmarks in new tab page. I don't use bookmarks toolbar because Firefox sync can't sync favicons and in a new install I would have to open all bookmarks to save their favicons. Humble New Tab Page can get their favicons automatically if I select to get them from faviconkit.com https://addons.mozilla.org/en-US/firefox/addon/humble-new-tab/
Thanks for the suggestion, but it doesn't look good for me. I have a ton of bookmarks, so I remove their names so that I only see icons in my bookmarks bar, seeing them in a column is not practical. I'll just keep using the extension I made for bookmarks and the one you posted for everything else.
I tried to change the bookmark favicon with userChrome.css It works, no need for an add-on, it works with userChrome.css It does change the favicon, but it needs the name of the bookmark. Maybe you can modify it a little to check the url instead of the name of the bookmark. Have a look at
EDIT
I've made some tests.
I created a YouTube bookmark which opens in YouTube container
YouTube ext+container:name=YouTube&color=red&url=https://www.youtube.com
My userChrome.css, it adds the favicon and removes the text from it (the way you want it to be)
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
.bookmark-item[label="YouTube"] image { width:0!important; height:0!important; padding: 0 0 16px 16px !important; background:url('https://i.imgur.com/lEpltc3.png')!important; }
.bookmark-item[label="YouTube"] > .toolbarbutton-text { display: none !important; }
Hi everyone,
I'm willing to look at this item. It looks like this issue is for adding the containers options to the bookmark menu, and a separate issue was opened for assigning a bookmark a container. So I'm only going to look at the bookmark context menu part.
@maxxcrawford can you mark this as assigned?
@kendallcorner Done!
@kendallcorner
and a separate issue was opened for assigning a bookmark a container. So I'm only going to look at the bookmark context menu part.
First of all, thanks for taking on the development of this task.
All of the separate issues for making bookmarks open directly with a container without a context menu were closed because project members/maintainers claimed it was a duplicate of this one.
Many many people explained how they are similar but also DIFFERENT requests. In my opinion, the context menu is the least valuable piece because having multiple bookmarks of the same website automatically open to a particular container is much more powerful. But I digress . . .
With you taking on only one task of this thread proves a couple things:
it proves that the project does care about improving the container tabs system . . . it felt like it was just in a stale state.
that they are DIFFERENT things. So hopefully, now with you choosing to address only one piece it will make it so the other threads can be reopened and not ignored.
so once again, these issues #1 and #2 are not duplicates of this thread . . . they are duplicates of each other but they are only repeated because they are NOT duplicates of this one.
btw, this thread has so many comments not because people want the context menu piece but because the people who want the direct bookmark system have no other place to comment because every other threads keep getting closed in error.
with all of that said, thankfully someone in the community listened and made an addon instead of waiting for the main project to do it which still isnt doing it.
https://addons.mozilla.org/en-US/firefox/addon/open-url-in-container/ is the community solution as describe in this comment
With #1537, our next release starts to address container-bookmark integration & UX. As @MichaelTunnell points out, it does not solve ALL of the container-bookmark UX requests in this issue, or in #854 #1142 and #1443.
Container-bookmark UX is a big project, and some of the solutions will require changes in Firefox itself. Any changes here could introduce tricky bugs both in technical integration and in UX flows.
We will soon on-board an Outreachy intern dedicated to work on Multi-Account Container issues like this one. Multi-Account Container users are a passionate group of advanced power-users with strong opinions about browser tab UI & workflows.
We ask for your patience as we start to explore this advanced feature space, and please be nice to the contributors who work on Multi-Account Containers. Thank you awesome Firefox users!
to be clear, I am very much thankful to @kendallcorner for taking on this task. I commented above just to make sure that this task wasn't completed, closed and the other piece be lost. Due to all the other threads being closed in error, I felt it might be necessary to clarify that they were mistakenly closed and still a very sought after feature.
with that said, @groovecoder that all sounds great with bringing in work back into Containers extension. You are right that many power-users use this feature and it might be something worth considering in terms of workflow and how it is addressed.
I am excited to see further expansion on the Containers system. It's my #1 reason that I love Firefox these days. :D
Please see larger context which also provide an interim workaround to avoid privacy breaches at https://github.com/mozilla/multi-account-containers/issues/1563
Check out the update released today. You can turn on Bookmark context menus in the add-on settings.
Possibly a controversial question, but since the latest release implements the bookmark context menu (you have to turn it on in the add-on settings) and #854 is open to cover assigning a container to a bookmark ... can I close this issue, or should I leave it open?
I have a site where I need to work with different user. In my mind a good solution would be two bookmarks:
Then I could type in the Bar "System" and select with the arrow keys the right Bookmark and depending of the Bookmark it opens in a other container. So for me is reason I subscribe here not solved.
Possibly a controversial question, but since the latest release implements the bookmark context menu (you have to turn it on in the add-on settings) and #854 is open to cover assigning a container to a bookmark ... can I close this issue, or should I leave it open?
Because the development team flat out refused to allow separating threads on the issue of assigning containers to a bookmark and insisted that this thread covered both topics even though the mention was an after thought . . . then I think this is most certainly not a closable issue until both tasks are complete.
I am thrilled that you solved the first issue, that is awesome! . . . but sadly since they insisted that this is a 2 part thread then both parts need to be done before closing.
Edit: I suppose I am being just a jerk about it . . . its just so annoying that it took 3 years for the issue to actually be acknowledged as a separate issue.
I mean, its just so frustrating because 2 years ago I said in one of the closed threads that "That is just bad organization and guarantees to bury the effort. Most people look at the first few and the last few posts." and now it finally has separate acknowledgement means its kind of like starting from scratch.
but anyway, I'm done venting I guess lol . . . the 3rd party addon covers it fine.
How does open bookmark in container addon do it? ? yu were able to open a folder of bookmarks in container chosen from context menu
This doesnt address the issue of other imported pages- onetab group, tree tabs group import?
I tried to change the bookmark favicon with userChrome.css It works, no need for an add-on, it works with userChrome.css It does change the favicon, but it needs the name of the bookmark. Maybe you can modify it a little to check the url instead of the name of the bookmark. Have a look at
EDIT
I've made some tests.
I created a YouTube bookmark which opens in YouTube container
YouTube ext+container:name=YouTube&color=red&url=https://www.youtube.com
My userChrome.css, it adds the favicon and removes the text from it (the way you want it to be)
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
.bookmark-item[label="YouTube"] image { width:0!important; height:0!important; padding: 0 0 16px 16px !important; background:url('https://i.imgur.com/lEpltc3.png')!important; }
.bookmark-item[label="YouTube"] > .toolbarbutton-text { display: none !important; }
Thank you, this works perfectly! For those who want to target by URL, just do .bookmark-item[image*="youtube.com"]
, for example.
There is a setting now in the add-on preferences to enable this functionality!
Go to about:addons
and select Multi-account Containers:
Right+click/option-click on a Bookmark or bookmark folder and go to "Open in Container Tab…"
@maxxcrawford That setting doesn't fix the other issue that was brought up, as has already been mentioned just comments above yours. We want a functionality to assign a container to a bookmark, so that the bookmark always opens in that container.
Friendly ping about what @rafaelgssa said. Should we open a new issue if this one will just remain closed?
Why doesn't the following solve this issue?
Is it where the domain is the same and you want to pin it to the bookmark itself, not the TLD?
Exactly. Having multiple account logins within a single domain this doesn't work. For instance, having a container on github for multiple users and being able to log into each one at the same time in different tabs without having to manually assign a container for each instance. Lots of sites will overwrite your login session if you log in to two accounts in the same context/container
@davidclarke-au as @caltheon stated, the reason this doesn't address the issue is because if the user wants to login to multiple instances of the same website they can't use this. If you could associate a container to a bookmark then you could have all of the different accounts organized in a folder and then right click folder, select "Open All in Tabs" and from here open each account in a new tab associated to their respective containers all automatically and simultaneously. This feature would be a massive game changer and way more useful than the other related requests once implemented, in my opinion. (technically possible via an addon but should be built in for reliability as it is a fundamental value)
As for why this thread should never be closed until this association to bookmarks feature is implemented is because it took the proponents of this feature 3 years to convince the repo maintainers that it is indeed a separate request. The maintainers insisted that this thread was all that was needed to cover both requests even though the feature we want is a secondary off-handed throwaway on this request.
Or might be even more useful if user could associate a particular bookmark with a particular Container so that it automatically opens in the right Container.
This one sentence stated by @gwynnarth as a secondary idea to the main point of the thread inadvertently locked the feature request we wanted to this thread because the repo maintainers insisted that it was the same thing. We kept trying to explain that all they were doing was burying the request inside another request. I predicted that someone would come around and pick up only the context menu request and ignore the other more useful piece because it was buried. This is exactly what happened.
Every time one of us created a thread to discuss this specific feature request they closed them all. They refused for 3 years to listen to us that it was a different thing and therefore needed separate thread to have discussion and to test engagement of interest.
So this thread should be forcibly kept open until #854 is completed because we had to wait years for that thread to even be considered separate so this thread should not be closed separately. This thread should only ever be closed as complete when #854 is closed as complete.
Edit: now that I think about it . . . this thread should have a label added that says "Sorry-854"
In hindsight (3 years gives you a hell of a hindsight indeed...) I must say that combining two very different (related but still different) ideas into one issue was a mistake on my part. I have naively hoped that maintainers will either treat them as inseparable and swiftly implement both ideas, or will create a different issue to track the secondary idea (for which I didn't have a clear usage example at the time).
From the experience of the last 3 years I can definitely say that this secondary idea is a better one and would be useful to a lot more people (myself included). And it makes me sad to see that various efforts to underline that these are indeed two completely different use cases were thwarted by repo maintainers for no good reason - after all it didn't result in both of these ideas being implemented here. Fighting ferociously to declare all those other issues as "duplicates" was just a waste of everyone's time 😔
TL;DR: #Sorry-854 and don't close this issue until we get "permanently assign a bookmark to a container" implemented.
I just started using containers. Since the need for a bookmark to open in a particular container is so screamingly obvious I thought that if I bookmarked a page that is open in a container that all future opens of that bookmark would open it in the same container. Silly me. Not only that but there is NO way in the base Containers functionality, as far as I can see, to even get a URL to always open in a particular container. In my view that makes Containers completely useless. I had to install the multi-account containers add-on to get that ability. And the UI for it is an awful 2 step process. Step 1: left click on the multi-account containers add-on icon and select "Always open in ..." at the conclusion of which it says "successfully assigned the URL to always open in specified container." But then when I click the bookmark I discover the authors have a different interpretation of "successfully assigned the URL to always open in specified container" from me. I get the dialog shown in https://github.com/mozilla/multi-account-containers/issues/323#issuecomment-666896405 asking me to confirm that I really do want to open it in the assigned container and to check a box if I always want this behavior and don't want to be bothered in future. Why the hell didn't you ask me that in the dialog from the add-on menu?
Given that this issue has been open for almost 4 years, I'm not holding my breath for any improvements.
@MarkCallow have you tried using the ext+container:name=Profile1&url=https://www.example.com/
ext+container:name=Profile2&url=https://www.example.com/
- it's not ideal but it does allow you to have bookmarks for the same URL and have them open in different containers and that can be used to manage multiple logged-in accounts for services that don't natively support that.
Selecting "always open in container" will override the bookmark, though (which makes sense for "always"). I don't know if there's a way to have a "default to this container" but I think that would be a separate issue.
It would be nice to have bookmarks support containers directly and not need to use the ext+container:
scheme.
https://github.com/mozilla/multi-account-containers/issues/323#issuecomment-666901198
multiple account logins within a single domain
For this, I use a complementary extension. See https://github.com/mozilla/multi-account-containers/issues/854#issuecomment-751410530
https://github.com/mozilla/multi-account-containers/issues/323#partial-discussion-header
Open bookmark into Container
This (the subject line) is, essentially, resolved as pictured at https://github.com/mozilla/multi-account-containers/issues/323#issuecomment-661273776
Open Bookmark in Container Tab ▶ …
Continuing to discuss #854 under #323 serves no useful purpose; people can simply discuss #854 under #854
Given the resolution, I respectfully suggest closing this issue. Thanks
@grahamperrin
Given the resolution, I respectfully suggest closing this issue. Thanks
I respectfully disagree and so does the original poster of this issue. The effort to make #854 to be accepted as an issue took 3 years for no reason because maintainers repeatedly closed it as a duplicate of this issue because they refused to listen to why it was different. Now that it is acknowledged that it is a different issue this issue should only be closed when #854 is due to the 3 year delay they forced on it.
If you want more info as to why here is a much longer version of the explanation: issuecomment-667159313
edit: now that I think about it, @gwynnarth would you mind editing your original issue post to include a link for #854 so people who are interested in that feature can quickly find it for discussion?
Focusing on the technical:
This isn't so trivial to implement, as from a quick look at the extensions API, it seems that although there is a way to determine whether a URL transition event comes from opening a bookmark, there seems not to be a way to retrieve further information about the bookmark itself (not even ID). The only carried information, that can be universally matched against the container mapping rules, is the URL for the transition. Please correct me if I'm mistaken. Because otherwise, the extension could just have an additional, customizable list of bookmark IDs per each container, and keep track of them, like it does for websites and their URLs.
Anyway, for those who don't want to scan the whole thread for a workaround, I'm reminding about the one that utilizes a protocol handler method provided by the Open external links in a container extension. The downside is that the URLs of bookmarks are modified (special format), which results in broken favicons. Other than that, it's a very clever way to achieve the desired behavior.
This isn't so trivial to implement,
It's implemented. Did you post to the wrong issue?
Only the context menu part is implemented. Quoting OP:
[...] might be even more useful if user could associate a particular bookmark with a particular Container so that it automatically opens in the right Container [...]
And then the big chunk of the thread basically revolves around that idea. It's not implemented. If the scope of this issue was only about the context menu, the issue should have been closed long time ago, and yet it isn't. The thread is still open, and active supporters of the idea don't even want it to be closed, until said automatic feature is implemented.
You're right that there is an another issue with a more specific title, so my post could fit better there. However, I'll dare to say, that doesn't make it invalid here, given all of the above. If what you're after is that there should be no more noise in this particular thread, then okay, I'm sorry for that, and I won't post here again. But really, in such case, keeping this issue open doesn't help anyone...
If the issue is the bookmark handler cannot support the functionality requested, and I assume getting that changed is probably a non-starter, would it make sense to change this to a feature request to add bookmarks to the container plugin itself to bypass the issue?
the context menu part
That was this issue, which is implemented.
https://github.com/mozilla/multi-account-containers/issues/854 is relevant to what's not implemented.
This would be very useful to me. It would allow to open a bookmark directly to a specific container. Further, it would allow to assign the same website to different containers, using different bookmarks, then open them with no extra clicks needed. When you need multiple bookmarked containers for the same website (as I do need), this bypasses the problem "open always in container" , which effectively blocks using multiple containers in the same website.
Hey all,
I'm moving this feature request to our new feedback platform Mozilla Connect so it gets more visibility.
On this platform if an idea has received a great deal of support (votes, comments) it will be tagged as "Trending Idea" and the Mozilla team is going review it for potential adoption.
Please upvote and comment on the following idea:
https://connect.mozilla.org/t5/ideas/container-preference-in-bookmarks/idi-p/3857
~~Currently it is possible to open a link that's on a page into a specific container by right-clicking and choosing appropriate "context" from dropdown menu, but you cannot do that with a bookmark, neither from Bookmark bar nor from Bookmarks menu. It would be useful to be able to right-click a bookmark and open it into a container.~~
Or might be even more useful if user could associate a particular bookmark with a particular Container so that it automatically opens in the right Container. So when I left-click "Facebook" bookmark it opens in "Facebook" container, when I left-click my Online banking website it automatically launches into "Finances" container.
Note: Edited by @dannycolin to make it clearer that opening a bookmark in a container is now resolved but that assigning a bookmark to a container is not.