kesselborn / conex Goto Github PK

2017-09-22 07:09:38.mp4.zip

i.e.:
always open *.reddit.com.* in container private

From #42 (comment) (2017-09-22):

… what does "when privacy mode is selected" exactly mean? …

I wondered the same thing.

No restarting with containment after starting with privacy

When there's a preference for Conex in the location bar, containers are not selectable. To me, that makes sense; I would not rarely, or never, something in private then (containment) make it less private.

When there's a preference for Conex in the context menu, containers are selectable but the page is not restarted in the selected container.

If it's true that there should be no restarting with containment after starting with privacy then the minor bugs here are:

• Conex should never appear in the location bar of a private window; and
• Conex should never appear in the context menu for a private window.

(If that's not true, then Mozilla should simply offer the option to restart a page without privacy. Beyond the scope of Conex.)

Conex in the toolbar of Firefox

Present but nonfunctional.

As Firefox allows use of Bookmarks and History menus in a private window, so Conex search results should be as good in a private window as they are in a non-private window.

Partly related:

• a bundled web page for Conex · Issue #52 · kesselborn/conex

... should only work, if user is ok with moving tabs between tabgroups

it's a mess right now

instead of opening a new tab

editing can perhaps be left out at first

as they will not be shown in the bookmarks section to avoid duplicates. However: this could confuse the user if i knows that a certain urls is a bookmark

... it's a mess at the moment

needs interception on tab creation

... and only for tabs that will be shown

From #18 (comment) (2017-08-28) with added emphasis:

… without the constraints of a sidebar …

… ideally a window, …

https://developer.mozilla.org/Add-ons/WebExtensions/user_interface/Bundled_web_pages

there is already a web-extension called taborama in the chrome web store. As webextension are compatible with chrome-webextension as well, I think this will just cause confusion.

Furthermore, my taborama actually does not have a panorama'ish view (which was where it was derived from), so the name does not make sense at all

Ideas:

• contaixt (container extension and similar to context) 👎
• contab or contabs (container & tabs) ... okaish?
• forklift (the vehicle that manages containers in a port) 👎

@grahamperrin as you already commented here quite a lot: any good ideas? Would like to do this rather sooner than later.

Option for context menu instead of page action · Issue #34 · kesselborn/conex is closed (thanks).

For around half an hour, at two machines, I struggled to understand why the menu option sometimes did not appear. Eventually I realised …

• Conex does not appear in the context of a tab.

Then, more subtly:

– Conex is in the second shot only because I took care to perform a deselection before presenting the context menu.

At 4e27b87 I see:

… much new code, will have to refactor …

– understood. No rush. Thanks again.

The tabs are in the wrong groups after importation, there must be in the previous one in the list ...

https://addons.mozilla.org/firefox/addon/taborama/versions/

Version 0.0.8
Released August 20, 2017 59.7 KiB
Works with Firefox 57.0a1 and later

After installing with Nightly 57, Firefox Sync installed the extension to 55.0.2. That's probably a Firefox Sync bug (I'm taking advice in IRC) …

… it also raises the question of intended version compatibility. https://github.com/kesselborn/taborama/issues/11#issuecomment-324830377 for example mentions 56.

Is there any feature of Taborama that should be functional with 57 that certainly should not function with 55.x?

Issue observed with 0.0.32, 0.0.33 and 0.0.34.

Also (echoes of recently closed reopen tab in other … default: does not work for contained tabs · Issue #36 · kesselborn/taborama):

• if Taborama is enabled
• and if Context Plus is used to re-open in another container
• then Context Plus can not reopen the tab to the default context.

This issue was first observed with Taborama 0.0.31 with Firefox Multi-Account Containers 4.0.1 with Firefox 55.0.3 (not supported for use with Taborama) on FreeBSD-CURRENT.

Reproduced with 0.0.31 with Firefox Multi-Account Containers 4.0.1 with Firefox Nightly 57.0a1 (not supported for use with Firefox Multi-Account Containers) on Kubuntu.

Steps

1. set the home page to about:profiles
2. Control-T
3. https://www.wikipedia.org
4. reopen tab in other … Personal
5. reopen tab in other … default

Expected

• default

Actual results

• again, Personal
• Control-N
• observe about:profiles, not contained (default, presumably)
• Control-T
• visit any page
• expect the page to be non-contained, actually it's Personal

Whilst the button in the toolbar is OK – movable (into e.g. the overflow menu), the immovable icon in the location field is an annoyance, especially when other extensions force immovable icons into that field.

Enhancement request

A user preference to not have an icon in the location field.

(Can you roll the functionality away from that icon, to the movable toolbar button?)

Thanks

when no tab, no history and no bookmark matches the search, offer to search in default search engine instead

Just opening this bug here for tracking. :)
https://bugzilla.mozilla.org/show_bug.cgi?id=1384515

https://addons.mozilla.org/addon/conex/

• refers to https://github.com/kesselborn/taborama/releases
• should refer to https://github.com/kesselborn/conex/releases

sub-topic of issue/24

• show the current usage on the options page
• option to cleanup all thumbnails
• somehow delete unused thumbnails ... however that is defined

only makes sense once https://bugzilla.mozilla.org/show_bug.cgi?id=1384515 is fixed

This is the context: mozilla/multi-account-containers#245 (comment)

Contrary to changing the container of an existing tab, there is no privacy implication to changing the container of a new tab in which I have typed the url but have not yet hit enter (possible exception: search suggestions; maybe require they be disabled to enable this functionality in private mode?).

Since the Mozilla folks seem not interested in responding* to that comment, I'm hoping you will be more receptive, or more receptive :)

*implementing or telling me why they think I'm wrong

For the current page action it permits the user to move across a container boundary.

This is a risky operation that is outlined here:
https://github.com/mozilla/testpilot-containers/wiki/Moving-between-containers

Steps to reproduce:

• Open a new tab
• Enter https://duckduckgo.com, but do not press enter
• Change the tab to a different container

Expected result: https://duckduckgo.com remains in the omnibar
Actual result: Omnibar is cleared

I know this is technically the intended behavior right now, but it feels like a bug to me.

Reduce the likelihood of confusion wherever any container-oriented product (such as Taborama) will be used alongside any tabgroup-oriented product.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

This may be better than use return new Promise(( and then().

(this came via mail, posting it here for visibility)

Sorry to write you out-of-the-blue, but I was reading some of your forum posts related to Firefox Tab Groups — and your interest in developing a Tab Groups-style add-on — and wanted to share an implementation idea with you before you got too far into a development project. Please forgive if I’m out of line writing you like this!!

So here’s my argument re: Tab Groups in browsers today:

If you ask browser users, "Why do you want tab groups as a feature?" they typically say, "Because I want a quick and easy way to organize my open tabs into logical named groups so I can work more efficiently.” They don't say, "Because I want to jump back and forth between an abstracted Panorama view."

Many Mozilla devs are fighting against Tab Groups feature requests because they think this means “reimplement Panorama,” which of course would be terrible. But even though Mozilla axed Tab Groups, users like us (as you rightly pointed out) still need some way to group tabs. And users like me find it frustrating to have to jump back and forth between a secondary, abstracted environment (Panorama) and the normal Firefox user environment anyway. We just want easy tab grouping. Many of us have several "workspaces" running at once, and need to quickly be able to jump between sets of tabs grouped logically.

I'd like to share with you a novel approach to Tab Groups that many developers aren't aware of, but that thousands of users have found ABSOLUTELY CRITICAL to their workflow. This basic idea blows Panorama out of the water.

Have you ever seen TabGroups Manager? https://addons.mozilla.org/en-US/firefox/addon/tabgroups-manager-revived

I cannot encourage you enough to check it out. It only runs in Firefox 54 and below, though (breaks in 55+), so be sure to try it in an older browser.

(1) The most important feature: The add-on allows the user to see persistent Tab Groups all the time in one browser window, without clicking a button or changing contexts. It creates one level of hierarchy (Tab Groups) which are represented as an extra bar in the tab area. (Please see the screenshots on the add-on page.) This allows the user to organize Tab Groups directly in the main browser window view, without having to flip to a secondary "Panorama" screen. The groups are always persistent on-screen. The user can create hierarchy, name the groups, and manage tabs (drag-and-drop between tab groups) in a quick, convenient way that provides visual context at all times.
(2) Secondary feature: The add-on allows the user to hibernate tab groups to improve performance.
(3) Most importantly, it resolves the weird paradoxes and inconsistencies with Panorama. The tabs are simply grouped in nested hierarchy. That’s it.

The problem is, Panorama has sullied the concept of Tab Groups for too many developers and muddied the etymological waters of tab grouping. Users who wanted Tab Groups indeed used Panorama (terrible implementation as it was) - often in combination with add-ons which extended its functionality to make it actually useful - because when Mozilla forced its will in implementing Panorama as the solution for tab grouping, there were no other options. So users made do with Panorama. Now that it's been axed, that's why many users who liked some sort of tab grouping feature are shouting for its return. Maybe they don't fully realize that it's not "Panorama" (poor implementation of Tab Groups, but the one that they recognize) that they want, but simply a useful implementation of Tab Groups. To me, it doesn't make sense to now be forced to have tabs completely disorganized, which is the current new paradigm in Firefox.

The concept behind TabGroups Manager is an incredible workflow booster. Of course, the add-on will no longer work in Firefox 57+.

My suggestion for anyone implementing new Tab Groups functionality for Firefox, whether core browser code or webextension add-ons is: Please implement this concept of “in-one-browser-window, always-visible, one-level-of-hierarchy” tab grouping.

A minor issue.

Steps

1. in a first window, in preferences for Conex, show icon in location bar …
2. open two more windows, browse to web pages, observe the icon in each window
3. in the first window, show menu for … containers in context menu (right click)
4. review the second window

Expected

• an icon-free location address bar

Actual result

• the icon

Workaround

• in each affected window, reload at least one tab.

Environment

Conex 0.0.51 on Firefox Nightly 58.0a1 (2017-09-28) (64-bit) on Kubuntu.

Taborama has a setting to enable/disable moving tabs between containers. It is convenient, but also a privacy risk, because it can leak information between containers.

Since v0.0.42, we can move new tabs between containers. This does not pose the same privacy risk, since we have not accessed the website yet, so I think it should be enabled regardless of which setting is selected.

and find out, what the problem is