Skip to content
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

Issue: Waterfox left FF before Update 56 --> Tab-Groups still works there!! #564

Open
ShonkaiDJ opened this issue Feb 22, 2018 · 8 comments

Comments

@ShonkaiDJ
Copy link

ShonkaiDJ commented Feb 22, 2018

I've been using Tab-Groups for a long while and as it was stated by some in these threads, my Websurfing life is completely dependent on being able to manage groups. My productivity will drop deep if I cannot manage my tabs in Groups.

I've connected to the developer here (Quicksaver who now can be a Lifesaver) and completely understand his reasons to end the life of Tab-Groups for Firefox. For Firefox. Because the Firefox has gone Loco. It leaves it's community that made it big and joins the corporate enterprise life. I whish them good luck.

So I moved over to Palemoon from (Beautiful name) Moonchild Productions. It has it's own profile and didn't see the need to change engine a long time ago. Yet: They don't have a working Tab-Group. Maybe some older versions of Tab-Groups would work but I liked the new and better functionality.

What does work there and is a native Add-on is also called Tab Groups (v0.3). It operates in combination with Tab Groups Helper (1.0.30) which is NOT a native but a Firefox Add-on. You can imagine I'm (Dutch expression) 'holding my heart' for the moment support for this combination breaks.

Today I discovered that Waterfox decided to start working with it's own profile and did not move to the new FF environment. Something I had been hoping for for a long while! And Guess what! Tab-Groups work! As we speak I'm surfing the web on my Waterfox which makes much more sense!

It's a fast x64 browser developed by a young idealist man. And it will not stop to develop which I feared at first considering the fact that it used to need the Firefox profile folder. And it's a bit more recent and modern then the Palemoon browser which by the way I also started to love while working with it for the last few months. Both Tab-Groups and Tab Groups/Tab Groups Helper work in Waterfox.

Porting from FF (Before 56) to Palemoon, Palemoon to Waterfox, Waterfox to Palemoon....it's all very easy. All profiles are compatible, Sync works. Or as I do: you can Restore Profiles from any of these browsers Backups.

What needs to be done for complete security now:

  1. Waterfox is going to need it's own Add-on repository and everyone developing for FF before will be able to join. (Palemoon has it's own repository but it's Add-ons are much more 'Legacy' to the Add-ons developers is my Guess. They would need to take a step back instead of a step forward.)

  2. The original Tab-Groups development needs to continue to stay up-to-date with the Waterfox project. For that to happen I'm quite sure our Quick(read: Life)saver will need more appreciation. A word that is Dutch is synonymous for Wage or Pay or Remuneration. Let's make sure that if there'd be an update, we do not leave our Saver behind!

  3. Both Palemoon and Waterfox may need their own 'Sync Repository' though I'm happy with the pre-sync solution that I still use called FEBE. If FF ever decides to throw out all Waterfox and Palemoon users from FF sync non of us know what will happen. All I know is I will reset to my Latest FEBE backup at that time and turn off Sync!

So much for my findings and at this point 2 solutions to save me from drowning and leaving me a happy surfer. I hope to see you guys Surfing safe Soon Too!!! (And as for Quicksaver: I hope you still want to do the effort in the Waterfox environment but if you don't I will understand.)

@ShonkaiDJ ShonkaiDJ changed the title Issue: Waterfox left FF before Update 56 --> TabGroups still works there!! Issue: Waterfox left FF before Update 56 --> Tab-Groups still works there!! Feb 22, 2018
@nezumisama
Copy link

Lack of (real) tab groups support is mostly what still holds me from updating from 56. And even in 56, tab groups seem to have issues (everything's slow, after restoring session I sometimes see tabs from all groups and have to choose one to fix this).

I can't imagine using a web browser without such feature for any serious work. I'm a software developer, I often have to switch tasks and it'd be close to impossible to manage without this.
I would start playing with the addon, maybe trying to fix the issues in 56, but firstly, I don't know the code and have never made an addon (only a small userscript), and secondly, I currently have multiple serious real-life issues I have to focus on and don't have any free time.

I was happy to hear the Waterfox guy plans on somehow keeping the old API alive. I don't know how he plans to do it, or if there's even a chance to pull it off, but I do support it, just as I support Quicksaver's addon and I'm ready to support those projects both as a programmer (I have some experience with both JS and C++, so I guess I could do something) and financially.

Mozilla pushed the incompatible API-change ignoring any issues people might have, and they didn't even bother to first migrate the functionality (deliberately dropping some functionality like the ability to modify UI). Obviously, at least management at Mozilla doesn't care about their former user-base and they want to continue copying ideas from Chromium/Chrome, I guess until they acheive a sort of singularity point, where those browsers will be identical, at which point they'll loose all market share (who want's to use some ersatz, when you have the real thing (and probably better)?). I understand there were technical advantages to the new API (in particular, I applaud they wanted to get rid of addons breaking core functionality and stepping on each other's foot), and I'm all for it, however, it shouldn't be done as quickly, and the API should allow to replicate every functionality from the old one, that's within technical possibility.

Recently, I've read that, after a few months of arguing about nothing and wasting time, FF 59 got an experimental API for tab hiding (hidden under a pref), which is the fundamental feature needed for something like tab groups. But, it turns out that this new API doesn't e.g. allow to hide the active tab. Meaning an extension will be able to switch your tabs, but the active one will remain. That's ridiculous! I feel like Mozilla is constantly playing with us, mocking us, first dropping the feature, then dropping the API, finally re-adding some of the API, but broken by design. I lost all hope for Firefox at this point.

@dgutov
Copy link

dgutov commented Feb 22, 2018

But, it turns out that this new API doesn't e.g. allow to hide the active tab. Meaning an extension will be able to switch your tabs, but the active one will remain. That's ridiculous! I feel like Mozilla is constantly playing with us, mocking us, first dropping the feature, then dropping the API, finally re-adding some of the API, but broken by design.

Nah, it's a simple limitation, for consistency: the extension has to make a different tab active first, before hiding the current one. Nothing unreasonable there.

@nezumisama
Copy link

nezumisama commented Feb 23, 2018

Nah, it's a simple limitation, for consistency: the extension has to make a different tab active first, before hiding the current one. Nothing unreasonable there.

I couldn't find in the tabs API (as described on MDN) a way to change the current tab, care to give an example?

Also, this is still unreasonable. Why is this limitation even in place? I'm guessing so that an extension won't hide all tabs, breaking the assumption that at least one is visible? But in that case, they could just add to the API a requirement to provide a non-empty hidden replacement tab set when hiding all visible tabs. And this limitation requires the workaround you described.

@dgutov
Copy link

dgutov commented Feb 23, 2018

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/update There's an "active" property.

But in that case, they could just add to the API a requirement to provide a non-empty hidden replacement tab set when hiding all visible tabs.

That's just splitting hairs. And your idea is more complex.

@ShonkaiDJ
Copy link
Author

Sincerely I do not understand why you guys are still talking FF. What a weird thread you chose to do so...there's supposed to be nothing but Water and the Moon here.

@nezumisama
Copy link

@dgutov
OK, I found out you're supposed to do update(, {active: true}). I don't like this anyway. For changing a boolean property of a collection, if only one item from it can have this property set, it would be far more logical to have a function taking an id. I also don't see how my solution is more complex. But whatever.

@ShonkaiDJ
Copy link
Author

ShonkaiDJ commented Mar 1, 2018

Ok Guys. Let me just show you that I've been working completely stable with Palemoon (x64) and TabGroups Helper and this week mostly with Waterfox (v56)and TabGroups. Completely stable. I am not a developer (I'm a system engineer with a lot of affinity with users though) but I could imagine the Developer of Waterfox who was 16 when he started this can really use your help if you know something. That should be more fulfilling than helping out a corporation that was build by our community. Waterfox is noticeably faster. Yet I really love the Palemoon project too. Please allow me to have you to take a peak into my private and professional life by showing you there is no need to fear change!

Good old Group of Tabs:
waterfoxtgroups2
From Good Old TabGroups functioning completely stable for over a week now:
waterfoxtgroups
And of course my latest view on groups of Tabs in Palemoon:
palemoontabgroupshelper

@ShonkaiDJ
Copy link
Author

I might as well point you to Alex Konto and the Waterfox project I think:
https://github.com/MrAlex94/Waterfox

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants