Solved Support Extensions

[TomAvatars]

I just started using Vivaldi and I love it. But I thought I read somewhere that it supported citrine extensions on mobile, and I just discovered it won't.
That would be a killer feature. Please do this, I need to use Roam toolkit and highlight!

[BoneTone]

@TomAvatars said in Support Extensions:

citrine extensions

I assume you mean Chrome extensions. If so, like/give a thumbs up to the first post in this thread -- that's how people "vote" for feature requests and relative popularity of a request is gauged.

Welcome to the forum.

[zakius]

I don't know if Brave uses Kiwi code or own one but it's supposed to get extensions support in stable by the end of June, maybe you want to take a look at that

[Sem69md]

@LonM I also agree with that because today date chrome brings all new extensions.

[Sem69md]

Please Vivaldi at extension support.
It will be very very good.

[sdoering]

Good news.

A Kiwi Browser guy now upstreams their changes to chromium. If Vivaldi is looking for excuses a little longer extension support may come automatically.

Here is the chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1074710

[Davy49]

Hi All,
I surely agree with what others have said about this subject, of course I'm not a developer but I know that if the chromium based kiwi browser can utilize chrome web store extensions, I would think that somehow the vivaldi developer's could do that as well.

[Catweazle]

@Davy49 , I used Kiwi Browser for a while, but compatibility with Chrome Store extensions was not as unproblematic as described and was quite buggy and deficient.

[BoneTone]

@Catweazle said in Support Extensions:

@Davy49 , I used Kiwi Browser for a while, but compatibility with Chrome Store extensions was not as unproblematic as described and was quite buggy and deficient.

And well, it didn't actually support extensions past a certain version of Chromium, if my understanding is correct. That's basically the reason it hadn't been updated in so long before the code was open sourced and project ended. So if you wanted extensions, you were relegated to a quite old version of Chomium (there hasn't been an update for 9 months, and the Chromium version then is even older than that if my memory serves). That can put the user at risk.

---

Also, something I'd like to point out for those that think Kiwi releasing its code suddenly makes it a trivial task for any other Chromium-based browser to support extensions, it's really not that simple. The issue above aside, let's assume for the moment that Kiwi was up-to-date with the latest Chromium. Forking the project would be the easiest way to make use of the code and build a browser with extensions support, but of course that's irrelevant to existing browsers.

It's not a straightforward task for existing browsers to simply pick up the code and have support for extensions. Nobody can just take the code, merge it into their project, and call it good. It's much more involved than that. In order to get it to work in any Chromium browser, the code has to be significantly modified. It takes a lot of time and effort, and compounding the problem is that the code is written by someone else, who may or may not be available to assist with understanding the code.

How well commented is the code, or how much documentation exists explaining the code? Since it's written by someone who wasn't a part of whichever project tries to use the code, it's pretty much a guarantee that the code is not written to match the coding guidelines and conventions of that project.

Even if the code functionally fits into one's project, and code be used without any changes to how it behaves, the proper thing to do would be to change it all to meet the standards of the project adopting it. Otherwise, every time there is a bug fix, or additional functionality added, the dev has to try to figure out what the code means, how it works, etc. -- an error prone process certain to cause issues at some point.

This is why software projects and organizations have style guidelines and standard coding practices that all developers must follow. It is difficult for someone to pick up their own code after having not maintained it for a while and understand exactly what everything is doing and why it was done that way, and in large projects people have to do that all the time with someone else's code. Well documented code that adheres to standards is essential to developing quality software.

These are just some of the things facing anyone who tries to use this code. That's the minimum every Chromium browser would have to do to try to use the code. It's possible that Vivaldi would require even more work on top of that, depending on how the extensions were implemented and how that compares to Vivaldi's code structure.

Many browsers could be looking at refactoring the code, at which point you might as well just write it yourself. It's not as if the code is solving some problem that other devs have never done or don't know how to do. It's really a matter of resources. If Vivaldi has the resources to convert all the Kiwi code into their coding standards, and modify its structure & execution to fit within Vivaldi's existing code, they have the resources to just write it themselves.

So this isn't the holy grail bringing extension support to all existing Chromium browsers we all wish it was. What it is best suited for is people who want to fork the code and continue the project. To get a jump start on a browser that's already functional with extension support started, but not workable with current Chromium versions. It is something to build on top of if you're happy with the approach taken to the problem. It's less suited however to merging into existing projects. There may be a browser out there that uses similar coding practices, and that would give them a nice advantage om terms of adopting the code.

Finally, after all that, there's still a major problem to address. Why doesn't the code work with Chromium versions released in the 10-12b months, give or take. Obviously browsers aren't going to downgrade their Chromium version, and the issue is so significant that the developer gave up on it and released the code instead.

Honestly, it seems like one would be merging in more problems than solutions to integrate this into an existing stable browser. It may be best to simply develop an in house solution like has always been intended. For the sake of both resources and quality.

The way this might benefit users the most is perhaps one or two niche browsers do try to use the code -- supposedly the Kiwi dev is working with an unnamed browser to try to incorporate his code into their project. This could basically drive other browsers to increase the priority of implementing extension support, and we'll get it sooner than we would have otherwise. Here's hoping that occurs.

[Zalex108]

@BoneTone said in Support Extensions:

So if you wanted extensions, you were relegated to a quite old version of Chomium (there hasn't been an update for 9 months, and the Chromium version then is even older than that if my memory serves). That can put the user at risk.

[gonkenstein]

I would be fine if the team just somehow worked in support for https everywhere, ublock origin, and cookie autodelete. They're all open source projects right?

[BoneTone]

@Zalex108 so yeah, it's running on Chromium that wad in ther version if Chrome released 8 months ago. There have been 6 major versions of Chromium released since then.

That's honestly not something I would consider suitable for everyday or production use. I'm more comfortable running a Vivaldi Snapshot or Firefox Nightly than that, neither of which would I recommend to someone needing a mission critical browser -- which an everyday/primary browser is, being responsible for protecting ther user's privacy and security. How many critical security updates is one lacking when using Kiwi?

Being a dead project, hopefully Kiwi can do what I expressed in my previous comment, and stimulate the broswer market to start implementing support for extensions. Like many (most?) people, I have a small set of extensions I consider essential to my browsing experience.

Currently I am using Vivaldi Android & Vivaldi Android Snapshot as my primaries for 2 reasons. First, it's so well designed that even lacking extensions my experience is as good or better than using Firefox, having direct sync of bookmarks plays a large but not exclusive role in that, and second, hopefully my use and feedback serve to reduce the wait for Vivaldi to release support for extensions. We can all play a small part in that by using Vivaldi and then taking the time to report any issues to the dev team. The additional QA coverage is something that no software project can replace regardless of resources.

[Zalex108]

@BoneTone

I had installed it a year ago for uBlock on some sites
Currently has been many months without using it but I kept it and follow the XDA Topic.

At least,
despite the old engine, still works and with uBlock it has some sort of security.

[Davy49]

@BoneTone Hi, I just wanted to take the time to express my thanks for you taking the time to explain the process for adding extension support for chromium based android o.s. browser's. To be honest, I never took the needed amount of time to think the entire process thru, and now I'm wondering if I should uninstall kiwi that I have on my phone. I saw over on this site: https://github.com/kiwibrowser . And while it does allow a user to utilize extension's from the google web store, by the chromium version being so old, I'm sure there are some security issue's involved. Also, thanks to your information now the picture becomes a LOT clearer as to why some of the other chromium based browser's available out there haven't added extension support as of now either.
David

[Catweazle]

I'm not a programmer and I don't know the ins and outs of including the ability to use extensions on Vivaldi Android. But I think that having tracking and adblocker included, apart from using Blokada and Quad9 DNS, privacy is already covered, at least in a basic way as far as possible in an OS controlled by Google.Naturally it is desirable to be able to add more filters as in Vivaldi Desktop and use other extensions, but for the moment and in view of the obvious difficulties, at least I have patience along with some common sense and excellent apps as workaround on F-Droid to enjoy, without a doubt, the best browser in the store.

[sdoering]

@BoneTone I think you are simply wrong in most of your assumptions.

Bringing the code to Chromium means it will be reviewed, all coding and documentation guidelines have to be met before it will be finally submitted.
All future changes to Chromium will be made compliant to this feature. If not it is regression and will be fixed.

And from the readings in the Chromium issue in most cases it's simple a fix, e.g. a wrong if-condition. But there are 400-600 snippets of those allocated along the whole project.

And it's not just the Kiwi developer involved. The first commit comes from a Samsung address. So the rumor goes that both teamed-up and the Samsung Browser wants to gain extension support as well.

The final integration times in other projects - like Vivaldi, Kiwi, Yandex, Samsung browser - depends on "their" forked Chromium. If "their" Chromium is nearly identical to the main Chromium the integration will be easy. If "their" Chromium is heavily customized integration will be hard.

Btw. Samsung and Opera are also using v77 of Chromium like Kiwi does. There is not much new between versions. But important bugfixes have been backported to Kiwi.

[Davy49]

@sdoering , Hi..more very interesting information & food for thought, I guess the bottom line is we need to be patient as far as extension's being implemented goes. Some things just take time to deal with.
David

[BoneTone]

@Davy49 said in Support Extensions:

I just wanted to take the time to express my thanks for you taking the time

Bitte schoene. That's very kind of you. I appreciate the note and am happy that it has been helpful.

@Catweazle said in Support Extensions:

I think that having tracking and adblocker included, apart from using Blokada and Quad9 DNS, privacy is already covered, at least in a basic way as far as possible in an OS controlled by Google.Naturally it is desirable to be able to add more filters as in Vivaldi Desktop and use other extensions, but for the moment and in view of the obvious difficulties, at least I have patience

I'm not a programmer by profession, the code I used to write for pay was mostly state modeling and automation, on the QA side of the development process. Even there, comments and other forms of code documentation were essential to making your code maintainable, by yourself or whomever would have that task I'm the future. One west coast MNC I worked for liked to sat your code should be half comments. They shouldn't describe what you're doing, the code should be written such that the how & what your doing is clear; comments document any interfaces and explain *why* your doing something or why it's being done that way.

20+ years later and I still write my code like this, even for personal scripts. I may want to make a change to something but haven't looked at the code in years, when my skills & thinking, and technology, were different; that practice makes it easy to pick up the code and start working.

Agreed, Vivaldi now has a baseline of blocking to help protect the user's privacy and security. Our patience with the Vivaldi dev team in the past has been rewarded with rather stable and complete initial releases when we do get our requests fulfilled. I've been very pleased with the Android browser, and I guess those few years of waiting and never really feeling at home with any browser I tried only served to increase my appreciation when Vivaldi Android became available as a public beta.

There are a few extensions beyond blocking that have become indispensable to me on the desktop and I simply would not use a browser without them in that environment. But even with respect to blocking, nothing really does what uMatrix does, that I've tried at least. The most secure way to run a browser is with a default deny-allow exceptionally policy, and uMatrix makes that very easy to administer and provides a great level of granularity -- and it requires no filter lists, third party or otherwise, making it a lightweight solution to boot. No other approach can replicate the control or experience.

[BoneTone]

@sdoering

My reading of that issue is that there is no new functionality being upstreamed, no UI, and no API. The changes being upstreamed are fixes to things that are weird and wrong and make it more difficult to implement support for extensions in a Chromium-based browser, not the implementation itself. Once all those changes are upstreamed, every Chromium-based browser won't gain extension support just by picking up the changes, they must still develop their own implementation. It just means that the implementation of extension support doesn't have to account for all these historical quirks, incorrect assumptions in the logic, etc. that shouldn't be in the code.

This is a good thing of course, as it is removing road blocks that unnecessarily complicate and make extension support less reliable. But it doesn't change the things I wrote -- the code being brought into Chromium is different than the code I was talking about in my previous post. Browsers wanting to support extensions need an implementation. That can either be done wholly in-house, or by trying to merge the changes from the open sourced Kiwi browser, or another open source implementation.

We're right back to the beginning of my previous post and all the caveats of trying to make someone else's code conform to a different project's standards, trying to understand the code in the first place, and rewriting any code that functionally doesn't fit. This refactoring of the code is nontrivial work, it takes a significant amount of time, as anyone whose had to work in an agile shop will attest. But no doubt the changes being upstreamed are a good thing that will only help, but more like making it how it should be without absurd additional bugs to program around, rather than a magical key to turn on extensions.

---

One other issue I didn't mention is the license that is used. The term "open source" just means the code is accessible but doesn't speak directly to how that code van be used. Depending on which license is used to open source the code, various limitations can be present, or people make us of the code may be required to do certain things in terms of distributing and licensing their own code. There are entire websites dedicated to this aspect of OSS, and I won't get into specific details here because it's a bit beyond my knowledge and experience, but it's something to be aware of. Vivaldi has code in it fron various entities which isn't open source, and their licensing of that code may prevent them from utilizing certain OSS projects due to the sticky nature of the OSS license. Just a possibility to be aware of, but the technical issues I discussed previously lead me toward the conclusion that the best approach in an inhouse solution regardless.

[Zalex108]

@Gurmeetim said in Support Extensions:

@Zalex108 How to down load this version
CAN U SEND LINK

ScreenShots are from the PlayStore one but on GitHub are newer updates.