Solved Support Extensions
-
@shmykelsa Unfortunately the Kiwi Browser available source code is far from complete and that's intentional, as the developer has mentioned in the past he doesn't want to give his work away (and there's nothing wrong with that).
Also the extension support is patched together on a pretty old chromium engine version so even if the source was available (which it is not) it would be far from possible for someone to simply take and implement on top of the latest available chromium. Even the Kiwi developer himself is having trouble transferring his extensions implementation to the latest chromium which is partly the reason why Kiwi has not been updated in months.
-
I had a season at the Kiwi Browser as a second on my mobile and this accepting extensions has never worked very well for me, that's why I have gone to UR, although like Vivaldi, it is still in beta, but it works much better and does not need the extensions That he would have needed in Kiwi, although he admits them.
>Laptop ACER, AMD Ryzen, GPU AMD Radeon RAM 16GB, SSD 512GB -Win11 Home 64 v24H2| Vivaldi last stable|
-
@Catweazle UR does not seem to support extensions, it seems off topic.
Firefox for Android does perfectly support them (including user script engines).
-
Now , Kiwi Browser Is fully open source. Take it from him for the extensions
-
@callionifabio said in Support Extensions:
Now , Kiwi Browser Is fully open source. Take it from him for the extensions
https://github.com/kiwibrowser?tab=repositories
Vivaldi could now and is encouraged to integrate Kiwis extension support.
-
Kiwi was recently patched to chromium 80.0.3987.58, it seems.
Just wondering why the Kiwi App is still on chromium 77...
-
Extensions is probably the only thing compelling enough for me to switch from Samsung Browser on mobile. Please make it happen!
-
Yeah the only chromium based browser that support chrome extension is Kiwi Browser right now.
But it lacks of syncing with chromium desktop (there were no version of Kiwi Desktop though)
Good news is on 17 April 2020, Kiwi Browser source codes are open in GitHub.
Perhaps, vivaldi team could look up on it.
There are lots of great feature there to be implemented on Vivaldi.
-
@Gurmeetim Vivaldi blocks ads well enough, but on certain sites, pop-ups are not blocked
-
This post is deleted! -
@callionifabio You can also use Blokada found on F-Droid.
But this topic is about extensions, not about ad blockers. It's more general.
For instance, I need other extensions, like user script (Violentmonkey), and user css (Stylus), mostly.
Fire this reason I use Firefox for Android.
I come from non-Chrome Opera, so Firefox was not good for me in the beginning so I went to Vivaldi first. But now after using Firefox for Android for extensions, I'm getting more and more used to Firefox on PC as well. -
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! -
@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.
-
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
-
@LonM I also agree with that because today date chrome brings all new extensions.
-
Please Vivaldi at extension support.
It will be very very good. -
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
-
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. -
@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.
>Laptop ACER, AMD Ryzen, GPU AMD Radeon RAM 16GB, SSD 512GB -Win11 Home 64 v24H2| Vivaldi last stable|
-
@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.
I post from my phone frequently, which likes to change "the" to "three". If you see three or similar, I probably meant "the". I use swipe, so typos can be totally unrelated words to what I intended. Knowing this should help you read through my typos.
