-
Notifications
You must be signed in to change notification settings - Fork 335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to bookmark a page to always open in a set container? #854
Comments
You still get this feature by opening the page in its container and then clicking on the Containers button (last time I checked anyway |
Doesn't seem to be working, either. |
You need to open the page in a specific container you want to bind and them click in the plugin icon and check the option "always open in container". But this only work to bind and address to one single container, so everytime you open that address it will go to a tab from that specific container. If you want to use the same page on multiple containers with distinct accounts them you need to open a container tab and them open the bookmark for each container. I would like to be able to have bookmark set to a specific container without binding the address to a container so i can have multiple bookmarks for the same address each opening in a distinct container. |
This is not a duplicate, containers are often needed for use two logins on one site. For example, I use 3 gmail accounts and we to have separate bookmarks for each of them, that will open bookmark in needed container. |
I agree, this is not a duplicate of #323, as this one is about storing a container information at bookmark level to always open this bookmark in this context by default - without further action of the user when he opens the bookmark. |
At work I have to be logged in with multiple identities in the same cloud platform. This means that simply assigning that site to a specific container doesn't work. And we also encounter a similar problem when using specific role accounts (separate users for normal and admin work) with web applications. Allowing a bookmark to open the site in a specific container would allow me to create separate bookmarks for the different accounts. |
Wanted to chime in and reiterate what other folks have said. It would be super helpful to designate a container at the bookmark level, so as to always open a bookmark in an arbitrary container. This enables myriad use cases, like being able to create bookmarks to the same service (e.g. Gmail) for different uses, like Personal & Work. Being able to assign a URL to always open in a container is not the same, and is actually counter-productive, as if you assign Gmail to Work, for example, the process to open Gmail in a Personal container is then circuitous. |
The same applies for me. I use multiple accounts for Microsoft tools (home, work, university) that need to be clearly separated. It would be really great if I could assign a container to a bookmark and that bookmark opens the page in the appropriate container. |
Agreed - this would be a great feature, and is not a dupelicate |
+1, not a duplicate. |
+1, would be a very helpful feature. |
#1050 is similar, but not the same issue. @groovecoder any chance this issue can get a second look? Are you open to contributions? |
Can we reopen or create a new issue for this? |
Source #323 (comment)
I'm a bit confused, isn't what #323 is trying to imply here? |
To me #323 is about right-clicking on a bookmark and opening it in a specific container. The way I understand this issue is being able to create, say, 3 bookmarks that each open a specific link, e.g. gmail, in different containers. |
It seems like comments here are being sent to the void, so I've opened #1443 in case any active developers aren't aware of the situation. |
From my point of view, how is this different from the latter? I believe both issues are the same albeit slightly different in workflow. That as if I am following you response correctly.
From my view, that's exactly what the other issue is trying to solve. Isn't it to associate a container with a bookmark? If not, please clarify. The intent here is to consolidate issues. |
It's not that it's going to a void, there is no one available to work on it. The one's who were active recently have went AWOL. Perhaps opening a issue to open existing issue my not be the way to go. And from what I understand @UserNaem should be able to reopen, however re-opening the issue doesn't necessarily mean any work will get done on it. Bear in mind, that issue has more votes, and more likely to see attention. |
We can agree there. But as others said, #323 is mainly about manually opening a bookmark in a specific container. It does mention that it would be nice to set a default too, but it's entirely possible that the issue will be closed/fixed without implementing both features. Also, what I meant by "the void" is that it's easy for closed issues to go unnoticed. I also don't expect every open issue to be implemented. I'm simply suggesting that it would be good to keep this issue open, just to ensure this feature request doesn't fall through the cracks. Ultimately, whether to have two open issues or one is up to upstream. I didn't open #1443 to tell them what to do; I opened it so that they can make a decision and act on it. |
FINALLY! We can now start to advocate for this feature again after waiting for 3 years for it to be acknowledged that it is indeed a separate issue. In the meantime though, there are some 3rd party solutions with this extension. https://addons.mozilla.org/en-US/firefox/addon/open-url-in-container/ and this other interesting method explained by @GodKratos, #323 (comment) |
Thanks @E1k3, I had looked in |
If you mean Mozilla's extension: there's the Bookmark Menus feature, but that's not page-specific (not bookmark-specific). |
Yes, @grahamperrin, it does not resolve this issue. It just makes life a little easier for average users to open a bookmark in a specific container. It's so unintrusive, I don't know why the add-on doesn't enable it by default. |
I see that this commit clarifies the use of permissions. But that's not the issue - I trust the developer doesn't do anything wrong with the data. The real issue is that if an extension is hacked and attacker pushes a malicious update, then he'll be able to leverage the permission I've granted when I installed the extension. Therefore, I as a security concous user, try to minimize any privlages granted to any extension. I very often forgo installing extensions on my main profile for this reason. |
I don't think that is what he was looking for.
You described it perfectly, that is what I am looking for as well. Anyone know if this feature is considered? :) |
@oscar230 I use this semi-manual method. It works 100% and is completely secure. |
I'm attempting to use the solution in #854 (comment) and I'm not having any success. It provides me with a link like below:
However, clicking a bookmark with this set as the url results in a page saying
I definitely have the extension installed and am able to use it manually. This specific container also exists. Is this a new regression or has someone encountered this before? |
Just verified FF 97.0 Bookmarked your link, clicked it from the bookmarksidebar and it opened in TestContainer. Is your setup different in any way? |
Ah, ignore me. I somehow completely missed installing the extension. Thank you for checking and sorry for the bother! |
Glad to help :)
…On Thu, 10 Feb 2022 at 22:52, Josh Arrington ***@***.***> wrote:
Ah, ignore me. I somehow completely missed installing the extension. Thank
you for checking and sorry for the bother!
—
Reply to this email directly, view it on GitHub
<#854 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANUVMK26RJVKHYNMDEQJU3U2QXTNANCNFSM4D4G7CFA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
#323 asked for two things and this issue is clearly a duplicate of the second thing asking to "associate a particular bookmark with a particular Container so that it automatically opens in the right Container". This definitely covers the use case of having multiple bookmarks with the same URL that each open in a different containers. I'm now closing this issue as a duplicate and will update #323 accordingly. Edit: Also, since #323 contains both feature request some users may have upvoted it for the assignment one. Closing #323 will mean losing the upvotes there (186 vs. 54). This means you'll have more visibility to advocate on the other issue |
This is one of the most frustrating threads I have been involved in on GitHub. Let me clarify, once again. THIS IS NOT A DUPLICATE! Why are we having the same discussion 2 years after it was already decided that it was not a duplicate . . . which took 3 years to convince the team of that reality. Just because someone said "or it might be more useful" in a post 5 years ago? The original thread is about right clicking and opening a tab via context menu. This thread was about assigning bookmarks to containers directly. They are VERY different features with very different scopes of development. One is merely deciding at launch and the other is a permanent connection. These are very different approaches and should not be slammed together. The problem, that I have been arguing FOR YEARS, is that if they are arbitrarily forced together then one will inevitably be ignored because the functionality required to do each of these requests is vastly different from the other. This means that the work to do one will very likely not help to do the other. Which would result in someone picking one of these requests and only doing that one and the thread would be closed completely skipping the one that would be "more useful". This is EXACTLY what happened 2 years ago! The context menu portion was completed and the direct assigning was ignored. These things are very different and are not functionally related as they have much different scopes so @dannycolin please revert all of these recent changes back to what it should be . . . separate threads for separate features. I am a big proponent of Firefox and Container Tabs . . . I have been using it since it was in Test Pilot and I love this extension. This extension is one of the main reasons I use Firefox and I have discussed this on my podcasts and youtube videos on many occasions. I just want to be clear that I am a fan of the work on Firefox and this extension but this specific thread is excessively frustrating. Edit: I would also request that issue #323 be updated to not be closed because the team made us wait 3 years to have a separate thread. That thread should only be closed when #854 is completed. There should also be a message in the original post at the top of #323 explaining that the first half of the thread is completed and for anyone who wants the second half be directed to #854. |
Are you kidding me? How on earth is my comment off-topic? |
@dannycolin : I can understand not wanting to address the issue. In that case, please just close this bug as a "WONT FIX", but closing it as completed and then marking genuine complaints as offtopic is quite disingenuous. I'm sure you're better than this. I believe in you. |
I'm following the same etiquette as on Bugzilla where offtopic/me too/advocate tags are synonymous. See https://wiki.mozilla.org/BMO/comment_tagging GitHub isn't as granular so I will unhide the comment to avoid confusion. |
@dannycolin Did you also hide the comments that contain the instructions for the only currently viable workaround? If so, why? I can see comments discussing the workaround remain, but not the ones that are actually useful to people who come across this issue: #854 (comment) #854 (comment) #854 (comment) |
For anyone interested - this solution still works perfectly well for me. It's super convinient to be able to specify GKE console should open on my work account etc.
Now when you call the bookmark it will open in the specified container. It seems like a lot of work but in my case I have maybe 4-5 often used bookmarks which I really want to be auto-containerized. The frustration this saves me is worth it. |
@Roy-Orbison It is now on the wiki. |
For anyone interested in this feature . . . it has now been migrated to a new Mozilla Connect platform with the url of https://connect.mozilla.org/t5/ideas/container-preference-in-bookmarks/idi-p/3857 We are apparently losing all of the comments and effort for support of this idea by moving this to a new platform for some reason so please go comment there to continue to show the userbase interest is still high. The previous frustrating thread has been locked so no one can comment about the migration, I just wanted to take this opportunity of this thread still being open to comment on a statement in the migration message which says the reason for migration is "so it gets more visibility" . . . I would like to point out that this thread would have had plenty of visibility without the excessively nonsensical closing of this thread repeatedly for 6 years. Yes, I do expect my comment to be hidden, deleted or whatever and this thread be locked as a result of my comment but honestly this is so frustrating that you and the other moderators dont seem to understand what the word duplicate means and now we are FINALLY getting the fact it is NOT a duplicate recognized but it took moving to a totally new platform 6 years later to do it. |
@MichaelTunnell I do appreciate that you are like me and a lot of others very passionate about this project and Firefox in general. However, I'd like you to take the time to read our Community Participation Guideline because your multiple comments are definitely trying to build hostility against the folks working on this project instead of being a constructive criticism. Unfortunately, I will have to lock this thread because of this and I will have prefer not to have to. To clarify @MichaelTunnell mentioning that:
This is absolutely false because if the Mozilla team decides to review this feature they will definitely look at #323 and its duplicates to get as much data points as possible to implement it the right way. |
Last time I checked, it was possible to bookmark a URL with the name of a container, making Firefox open that page in the specified container from this bookmark. I can't find anything referencing this functionality in any manuals, however. Was is removed? Or maybe I wasn't looking hard enough?
(Having to hold the new tab button for a whole second to get the containers menu feels terribly slow, by the way.)
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: