Ladybird can be also easily ported because it has Qt backend. @3dEyes also made experimental native port.
1 Like
It could play youtube videos. Nobody bothered to write the “proper” media code integration. I won’t because for my case because I don’t care one bit about youtube and their monopolistic garbage behaviour. (like explicitly trying to make safari and firefox slower)
Your “platform specific interfaces” are really just normal Haiku code. Rendering controls uses the controllook library, like in any other app that would draw it’s own gui. (like qt)
Media playback requires media kit… like in any other layer that implements media playback itself (like SDL2)
It really isn’t difficult.
Why do you think that Haiku Inc has anything to do with what developers work on? It clearly doesn’t. It’s there for bookkeeping if donations, nothing more, nothing less. It has nothing to do with this conversation.
2 Likes
Then why it is not done yet? Writing new code is more difficult than building existing code fixing minor build errors.Writing new code inside another project is even more difficult.
Then why do you think that porting new browsers and new browser engines is a problem? More available software, more choose, is better. And it do not harm developing WebPositive because it is done by another people with another skills and goals.
1 Like
I think having it’s own browser is important for a any OS. Because, you will need it to display docs manuals or simply the project web page, you need it to be included in base install.
Knowing that you can’t rely on an external project because you don’t know their politics or license won’t evolve to something not acceptable like telemetry. So, IMHO work on webkit is necessary to achieve independence of the project.
The browser included doesn’t have to be top class and you can have another in depots. But having its own browser that does the job is also a good publicity. Few would talk about Serenity OS if there was not Ladybird.
2 Likes
While it’s not a showstopper for me – a 99% Web+ user – it is a bit awkward copy and sending a video-URL to yt-dlp. And it’s not just YouTube, of course.
Personally, I’d very much appreciate @waddlesplash taking some time during his contract work to have a look into what’s needed to make video streaming work. It’d make using Haiku more convenient, possibly improving the MediaKit, and along the way shutting up the first complaint any reviewer ever had… 
3 Likes
No, that is a choice I made with my porting efforts. It is possible to build WebKit with GTK, or with WPE embedding framework.
It is also possible to not build it with that, but still enable GStreamer and Cairo.
Because no one has done it.
Why have I not worked on it recently? Because I don’t have a working soundcard driver on my laptop yet. So, playing videos on Haiku isn’t a very interesting goal to me at the moment. It surely will when I get my soundcard working (which I have made some progress with help from korli this week).
The last time I worked on it, it took me maybe two days to connect WebKit APIs to BMediaFile and BMediaTrack. It wasn’t particularly hard. At the time, these classes didn’t support network resources very well. This has since been solved, with code available for example in StreamRadio to handle this better (with buffering, not needing to load the entire media to RAM before starting to play it, etc).
Then there is a bit more to do for a really good experience: performance improvements in sending the picture to the display, and likely implementing “real” fullscreen support in WebPositive.
And, yes, that part is a little more work than porting an existing browser. But it is less work than porting an existing browser that involves also porting GTK, making a Wayland compatibility layer, fixing many issues in Haiku memory management, finalizing ramfs and making it able to share UNIX socket file descriptors between applications, and all the other things that have been done.
It’s just different people having different ways to approach things, different goals, different skills. There is no need to be so aggressive and defensive about it.
I think regardless of that discussion, WebKit is an interesting option to look at. Also if it’s in the form of gtkwebkit or WPE-WebKit.
4 Likes
I agree fully. You and the other folks working on our WebKit port have done an amazing job. The only rub is it still has a ways to go to be a daily driver:
- Performance (A lot of sites are fast, a lot aren’t)
- Plugins (password managers have become pretty important)
- Stability (WebPositive still crashes after around 5 minutes of browsing the web… especially individual tabs hanging up)
The IceWeasel port is a big improvement on the above (with substantially less development time), which is why so many people gravitated to it.
@PulkoMandy any ideas on how much more work is needed to get our changes upstream? Webkit stuff moves quick as we all know (getting 100’s+ commits a day)
1 Like
My experience is the complete opposite: Iceweasel tabs sometimes continually crash on some URL, where Web+ is normally quite stable if you avoid the WebSocket thread of death of Github etc.
Some sites just won’t work under Web+, though, so having an alternative is very welcome and much appreciated!
4 Likes
This is fixed in the last development tree. It was a one line fix. Why no one looked into it for years and people decided to port entirely new web browsers, I will never understand.
Someone needs to split it into reasonably sized patches and submit them. I have already started. All our changes to cross platform files in WTF where we just added a || PLATFORM(HAIKU) to existing platform specific paths or added just a few lines of custom code are upstreamed already, and that resolves most of the issues with merge conflicts.
I am in the process of doing the same with JavaScriptCore.
The WebKitLegacy part won’t get upstreamed, this was already being deprecated back in 2010 and now it’s really on the way out. But we’ll see when we get there, before that we have to upstream the patches to the build system to know about Haiku, and the remaining parts of WTF, as well as changes to WebKit core to add the app_server backend, the netservices backend for network (if we decide to upstream it, since now we’re using curl and that code is currently dead and likely broken), and so on.
2 Likes
Oh yeah, WebExtension support is paramount for me to daily-drive any web browser in a serious capacity.
uBlock Origin is one of the biggest extensions that people use. I use some of its features (element zapper, per-site content toggles, etc.) that go beyond just block lists.
SponsorBlock has also become rather prominent, however it does have an API which allows for deeper app integrations.
Dark Reader meanwhile is necessary for accessibility. Some dark modes of websites are so awful for readability, that having Dark Reader enabled for them becomes a necessity. This also applies in the inverse for light modes, too.
1 Like
I don’t get this concern at all. Most of the concerns listed in thsi thread with “we need addons for this” seems like stuff that should just be in a webrowser normally.
1 Like
Falkon has a built-in ad blocker which in theory uses the same rules lists formats as uBO… but it doesn’t support nearly all of uBO’s blocking features, so the experience is just not as good, by a significant amount. I haven’t tried WebKit’s built-in adblocker (which again uses the same format), to see if it’s much better here, but thus far I haven’t heard that anything is truly at feature parity with uBO.
4 Likes
It doesn’t. I know adguard on ios/macos can use this, but it converts the filters. The syntax is this:
But regardless, if that syntax is insufficient we can likely extend it (note that is probably already does not support only what this 10year old post outlines)
uBO is also at the forefront of defeating Google’s anti-adblock measures for YouTube too, which during the height of the conflict required daily extension updates. Google has since seemingly backed off for now, but who knows when they’ll ramp up efforts again.
uBlock Origin is not just about a set of rules. It injects custom javascript to patch things. And, maybe more importantly, it is being continuously updated in the background to adjust to changes on websites.
“these features should be built in to the browser” kind of misses the point. What makes add-ons interesting is the high customizability, in a way that nothing built into the browser can really provide. Deciding that some features are really important and should be in the browser can come later or independently, but in several cases it will be a big reimplementation effort, while add-ons already exist for many things.
The debate is not dissimilar to native vs ported applications, and the answer may be the same: can native features ever catch up with add-ons and ported software? Maybe it’s ok that ported software and add-ons exist, and native applications appear a little more slowly but take time to do things better.
3 Likes
Sure, but that isn’t really what people mention in relation to addons. So Far every time I have seen this mentioned it was in the sense off havibg to use addons in other browsers to fix major deficiencies, and hence we should do this the same way.
I really disagree here. Forced colors is something webrowsers implement themselves, edge does this. Adblocking is something that also has to be build in. The api in web extensions is a hammer in this sence, but not every problem is a nail.
The adblock api in webextensions has unfixable problems like races. Sometimes ads will just get through because the add-on took too long to load. (and also extensions can read all traffic this way, which is not really nice either)
The only way to fix this is to delay each pageload, because you have extensions.
Not even the hosts file blocking method has this problem. And so far I am not really covinced by the argument that those scripts do anything relevant. I use safaris adblocking daily with a loaded list and basically never have ads go through, and if they are this is because the list is outdated and i don’t update it automatically.
The usecase of “pick this element to block this” is also something safari has build in already! Both in the case of dev tools, aswell as in normal useage for “block annoying content”
maybe this is a ported vs native debate for you, but I care since this is about setting priorities. I don’t think the arguments of why webeytensions should come first are really convincing when pretty much all issues listed are to fix major deficiencies in the browser itself, that also can’t be properly fixed by extensions.
And in either case, if ported stuff is preferable, iceweasel and falkon are already available.
I would rather investigate the CONTENT_FILTERING build option for webkit first, and later when the Major functionality works investigate webextenions ontop of that. (which also happens to be a build option)
1 Like
I guess that in some cases web extensions are used for political reasons. “See, we are rendering your web site perfectly.” and “We don’t have control on extensions that people are installing.” are coming to my mind. For who is developing the browser, it is also quite convenient because some of these extensions are on the edge of what is legal or not (like video downloaders) Some are definitely used to websites policies (like those allowing you to create multiple accounts on social media). Also, this kind of extensions are requiring a lot of attention because, of course, websites are reacting. It’s an endless fight and the winner the fastest to react. If you’re a company developing a browser, you don’t want to enter in these polemics nor spending precious time to do that job.
The priorities are set by people who will be doing the work. Mine are simple and unambitious due to lack of time:
- Merge upstream changes from WebKit regularly, so whoever works on it starts from a reasonably up to date base and not a several years outdated one,
- Fix build issues while doing this, by doing the minimal needed adjustments,
- Try to not introduce too many regressions, and fix them when they inevitably happen.
In that context, my next tasks are not enabling extensions or content filtering or anything else. My next tasks are:
- Upstreaming our changes (this reduces the work in the “mergin” part)
- Fixing the webkit test suite on Haiku (this should help a lot with the “no regressions” part
At the extreme, anything else (videos support, web extensions, content blocking, webkit2 port) means there will be more code to maintain and, in the current situation, just makes my job harder.
Now, this is not a reason to block everything. As x512 pointed out, this has been the situation for the last 10 years, in which I have not done much but this basic maintenance. That is already a lot of work. I believe switching to another web engine does not change that: the maintenance, just keeping it running and up to date over time, is a lot of work. Maybe some other people can do it better and more efficiently than I do. Maybe with WebKit or maybe with another engine. I would not complain about that, it would be less work for me.
But, what I have seen so far, and multiple times, is people putting the initial work on the “new and exciting” part of porting a new web browser or engine to Haiku, and then not doing the maintenance part. Usually with very good reasons, so I do not blame them. The old Firefox 2 port was abandoned because Firefox was moving too fast and permanently changing its dependencies at the time. The Qt WebKit port was abandoned because Qt switched to QWebEngine. Ladybird is in a situation where the initial port was done while it was part of Serenity OS, and the new Ladybird after the split seems to be taking a quite different direction from the original project. I am not sure what happened to the QWebEngine port, but I think Google’s hostility to non-mainstream operating systems would prevent any hope of upstreaming there. I don’t know what happened or is happening with GTKWebKit (I have not seen an update in a while) and Firefox (the port is still pretty new, we’ll see how it goes).
I know of another engine that has been kept up to date with upstream over the years: NetSurf. In that case, mmu_man did the initial port of the engine but I’ve been doing the maintenance since then. Fortunately for me, it is not nearly as active as other projects and has few dependencies. This means my only work is checking that things are still working every few years when they make a release.
So, work on whatever you would like to see. Just make it happen. But maybe think a little bit in the long term and how the thing will live, how much time it will cost you or someone else to keep it running.
1 Like
I think that has bern worling fine for us, no?
My priorities are getting webkit2 in a functional state. And also somewhat based off of your motivations, if I can get webkit2 to work nicely we can switch webpositive and no longer have to maintain webkit1, and have the option to upstream webkit2 which should make your job of just maintaining it easier.
I have made the odd feature addition aswell, and tried to improve rendering.
Though I certainly wouldn’t have been able to as easily without you maintaining the base! so thanks for that.
Keep in mind though that I am also happy to do haikuwebkit releases, I have permission from disroot to have a copy there, so I would tag it there and that version can then be be used from haikuports. (Only for the case of rebasing on upstream I don’t yet know how to nicely do this, but we can talk about that I reckon)
I have avoided doing that on my own because I don’t want to step on your toes, and you tend to make releases a bit quicker than me. (Also because I try to put changelogs on the forums, which isn’t always neccesary)
13 posts were split to a new topic: Discussion about moving Haiku repositories from Github to Codeberg