There is a reason for that. Although questionable, it keeps the iOS/iPadOS sandboxed environment mostly secure.
Don’t forget about Safari on MacOS, which currently is my favourite browser, btw. Besides some OS specific features, the engine is pretty solid, lightning fast and the memory footprint is smaller than Blink based browser.
I would say that, as long as there is Apple there will always be a WebKit. So I’m inclined to say that WebKit is the right choice, not Blink.
That is my personal humble opinion, of course.
5 Likes
They don’t prevent you from porting it, of course. The matter of fact is that they do not accept upstream patches for operating systems other than MacOS, Windows and Linux.
I would like to, but the webkit2 code and git history is not clean enough for my standards. Also, if the code is not working and no one is using it, it just rots in place and it will be very hard to find when it was working. It’s much easier to do that if the code is kept in a separate branch for now.
When it works, I think we will not take very long to move WebPositive over to webkit2 and delete the webkitlegacy code anyway, there’s no reason to keep it alive once the new version works.
5 Likes
That makes sense. Although I’m not a coding champion, I would like to help and will look into the WebKit2 code. Do we have a ML, IIRC or whatever (even Github itself) to discuss?
2 Likes
Irc (#haiku on oftc) or the development mailing list ( Mailing Lists | Haiku Project ) would be prefered for this (although the forum is probably “okay”), there is no webkit specific communication channel at the moment.
Specific changes can be discussed also on githubs code review, or on the bugtracker.
1 Like
Warning: Rant Ahead
I agree with the stupidity argument if you mean that having monstrously large web engines as a basis for a browser, just for compatibility reasons, is the greatest stupidity of the worldwide web. Modularity would have been better served as an engine made up of sub-libraries.
Unfortunately, starting over is not an option any more. When Mozilla tried to replace Firefox with Servo, their new and shiny Rust based browser, they found that even they couldn’t do it. Finally they ended up turning the code hosting and maintenance over to Red Hat. They are still trying to incorporate Servo’s code into Firefox over time using C++ bindings to Rust.
Once a Blink-based monoculture is established we fall into the same trap as we almost fell into with Micro$oft Windows in the 90’s. The only difference would be that Web Apps based on the Blink engine will not have the advantage of antitrust hearings to try to bust up the monopoly. Blink is maintained by Alphabet, sure, but isn’t the Blink source code an open-source licensed project? Just put a non-profit foundation packed with industry insiders as directors and trustees and the big tech trifecta of Microsoft, Apple and the Linux community will be complete in their internet dominance. Blink just can’t be a Haiku solution for the web.
A Way Out
While WebPositive is the current solution because it can try to piggy-back on WebKit2’s existing code base, we need another way out for the industry, and Haiku in particular.
A transition from Web standards to simpler ones could include dedicated internet applications. Do you remember when IRC clients weren’t written in JavaScript? When bulletin boards ran in text-based terminals? When NNTP clients on Usenet were many times more responsive than forums like this one? Those functions were well served independently of the browser.
My thinking is that modularity can make a comeback if we quit arguing about alternatives to WebPositive and start making alternatives to the protocols that require its use. Of course we’ll need to cherry-pick from among the existing protocols to find ones that work well.
Started a new thread for related discussion.
5 Likes
It must have been an earlier version, it was not on haiku though. I remember having trouble with it, but I last built webkit ~10 years ago. The first google hits suggests this was indeed true in 2012
https://forums.gentoo.org/viewtopic-p-7093866.html
/rant
When I say stupidity, I mean increased complexity with no end user benefit, I am just not seeing the gain of user functionality with the ever increasing complexity of the web. Innovation for the sake of innovation is not progress. It is a lot like the never ending growth of managerial culture in government and business.
At 1 point, GM had 76k white collar workers and 78k hourly workers.
I think it’s the MBA problem, but with programmers and team managers. The goal of everything should be to reduce complexity to the lowest possible level. The best part is no part and the greatest sin of any engineer is to optimize a thing that doesn’t even need to exist. Musk isn’t wrong here.
rant/
3 Likes
Maybe Flow engine might be interesting. If not for code, then maybe as a concept.
https://www.ekioh.com/flow-browser/
https://www.fastcompany.com/90611677/flow-ekioh-web-browser-new-engine
3 Likes
Oh look, it is this thread, again.
Dear naysayers: try to use the search function on the forum and actually read the results, we dont need yet another flamewar about your feelings, ideas and favorite webbrowser. If you cant add anything new then consider to not open a topic.
Also please consider to divide a different community (thats a *nixy habit btw) with your shiny ideas, thank you for the understanding.
1 Like
It is not about the topic but about the people who came up with the same ideas in every 5-6 months.
“Guize, i have the greatest idea, you should port my favorite webbrowser, this is the only way. Also switch to the l*nux kernel in the same time. I am a genius. I also wont touch any code, so please do everything as i suggested. Now.”
Please grow up.
3 Likes
in the ability to transfer data between apps (copypaste or drag and drop for complex objects, not just plain text, etc).
Speaking of which, the WebKit port doesn’t currently have drag-and-drop support, right? I’ve been looking for a complicated program to test Emacs with, but all I can find is Tracker, Pe and StyledEdit.
It doesn’t?
Open a ticket and I’ll try to look into it :)
First it was derailed, then you made a second topic. why not start the new topic first?
In any case, it does not matter much, currently Haiku needs a webrowser, full stop.
There simply is no way to use many modern services without it, like informatin from a local city etc.
This is regardless of weather some parts of the web are overly complex, the not so complex parts have to work. This includes streamed media, this should work properly in haikuwebkit and MediaPlayer. Maybe even using Picture in Picture handoff to MediaPlayer.
We can’t sit on out hands and complain that many parts of the modern web are shit if we can’t solve any of it. This won’t help getting people less dependant on it but rather more as they can’t use Haiku then and instead will be pushed more into chromeOS or windows.
1 Like
No that’s a bad hack. If we can’t play a video without the help of MediaPlayer, we should not dig ourselves deeper into that ridiculous situation. We should move code from MediaPlayer to the media kit so that normal humans can actually use it with an API that does not require a galaxy brain and a PhD in BeOS history to understand how the media kit is architectured.
So let’s fix that and not pile up hacks on top of it to avoid the problem.
10 Likes
I didn’t suggest using MediaPlayer as the thing to play media with normally, I think it would make sense to implement PiP with it, the playback inside the browser would be in the media kit anyway.
Currently streaming works badly in both of them, so the media kit would be a good place to fix this if we need streaming support.
is there a open source library in one of the other browsers that could be used to fix the streaming issues, or is that part of the network services project ? did that ever get clower to completion ? kit know it’s been worked on over the years. i thought the new network services stuff had to wait for webkit2 multiprocess design
- WebKit (legacy) builds to completion. (recently updated)
- WebKit2 builds (but required repatching a few areas). (not recently updated)
Testing is very close to Webkit/Safari test results. Issue seems mainly wiith Haiku API integration/features work.
If focus is on Webkit2 build, someone can update it to a recent snapshot (I did this before on my own fork(s)) and we can focus on fixing the builds from there… (start decommisioning WebkitLegacy at some poiint)…
7 Likes
WebKit could use GStreamer for that, but it would be better to use the Media Kit I think?
Well, GStreamer is possibly easier but doesn’t help with improving things for native apps, and it’s yet another dependency added to Haiku (and not just one, GStreamer in turn brings lots of Linux stuff).
Similarly, the network side can be done either with curl or with the native netservices (both already work and it’s easy to switch with a few compiler flags). Likewise the graphics could be done either with app_server or with cairo, and so on.
5 Likes