What is the flickering header good for?
Make it scrollable? Move with page old school?
Remove it?
What os the easiest way to get a good Haiku experience with Web+ and Sites important to use with Haiku?
Github, Forum, Main Site shold work perfect with Haiku.
I doubt this has anything to do with performance, just a bug. other elements work fine when scrolled
âEasiestâ is often not best. The best solution is to fix the way the browser handles this - changing Haikuâs discuss to accommodate a Web+ issue is still not going to fix it on - say - Gitbub. If everyone changed their sites to accommodate IE and Active X in the 90s, weâd be living in a different world⌠(And not not a better one, as sub-optimal as this one may be). If Haiku aspires to be a modern OS for the masses, Web + has to keep moving towards full support current web standards, as crappily as they may be implemented out in the field.
That said, I do not find a flickering re-render of a header bar to be the highest priority issue in Web+
2 Likes
I just upgraded from hrev55410 to hrev55427 due to an odd boot issue that impacts my machine in some builds⌠Iâm not sure if it is just my imagination, but Web+ seems a lot snappier in this build. Nice work - Web+ is really coming along.
1 Like
The only commit in that range which might have impacted performance is hrev55422, which replaced some rather obscure POSIX functions with much more optimized versions. I would be surprised if WebKit or anything it uses used these (I know that WebKitâs templating library has replacements, so, it would probably be a dependency of WebKit if anything), but you can experiment to find out by forcing WebPositive to use a libroot.so from before that version and see if it is indeed slower.
2 Likes
QuteBrowser and QtWebkit both sound similar with the first syllable sounding the same but looking different. What is the difference between in the Webkits? Obviously Chromium uses its own derivative of Webkit as was explained in the above article but Iâm confused.
WebKit is a web engine developed mainly by Apple with help from other companies.
Blink is a âforkâ of WebKit (copied some version from 2014 and made a lot of changes based on that version) by Google and used to power Chrome and Chromium.
HaikuWebKit is a version of WebKit that uses Haiku APIs directly and is used by WebPositive. It is up to date with the latest version of WebKit available.
QtWebKit is a version of WebKit based on Qt APIs. So, running that on Haiku is an extra layer of software (the Qt libraries), but it allows to reuse applications coming from other operating systems. More problematic is the fact that the developers of Qt have decided to go with QtWebEngine instead. So, QtWebKit is not updated anymore, and will not be. Now Qt applications use QtWebEngine which is based on Blink/Chrome. Some applications can still be compiled to use the old QtWebKit engine, but that will become more and more useless as times moves on and websites become incompatible with it.
Currently QtWebEngine is not available for Haiku. The team at Google who works on Blink and Chrome seems to be not willing to support anything else than Linux, Windows and MacOS. They have rejected patches for FreeBSD and OpenBSD support, so versions of Chromium for these systems have to maintain their own fork of the code and do a lot of patches that will never be integrated. On the other hand, the WebKit team has integrated support for these operating systems, and they are willing to integrate the Haiku port as well. We just need someone to clean up the patches and submit it to them.
I hope this gives a better overview of the situation.
14 Likes
QtWebkit is a layouting/rendering engine, like Trident/Gecko/Presto.
QuteBrowser is a user interface for the render engine, the browser itself, so to speak.
1 Like
Tested x86 and x86_64 builds (Webkit 613.1-based):
- Dropbox - haikuwebkit_x86-1.8.2-3-x86_gcc2.hpkg - Simplify your life
- Dropbox - haikuwebkit-1.8.2-3-x86_64.hpkg - Simplify your life
WebPositive now works pretty good on x86 and x86_64.
Many previous website crashes seem resolved. Youtube is working ok. A few fonts get scrambled on IRC (new issue, upstream font system changes), but mostly works now.
WebPositive on x86 reports:
Haikuwebkit 1.8.2
WebKit 613.1.3
7 Likes
Does that mean those are in the nightly at the moment? Noticing the github link sends to a commit.
Edit: Did try to install the hpkg, but got an error. Running the stable version, so I assume thatâs the issue.
No. The commits doesnât lands automatically in Haiku. PulkoMandy decides when he tags a new version.
Anyone in the haiku team can put a tag on the github repository and make a new release. Please donât put all the responsibilities on me. I happen to have done it because no one else does for the last few years, but I would certainly be happy to see that change and work on more fun things instead of being forced to update the web browser everytime I try to do something in Haiku.
6 Likes
It wasnât responsibility pushing, but one can understand it like so, thatâs true.
Then let me formulate differently: changes in HaikuWebKit doesnât shows up in WebPositive automatically. So far the process looked like this:
- after enough changes accumulated in the HaikuWebKit repo a new release was tagged
- the HaikuWebKit recipe in HaikuPorts got updated with the new tag and checksum
- recipe gets merged, buildbots building it
- WebPositive code gets adjusted (if necessary) to the new HaikuWebKit version
Or something similar.
Some crashes were fixed by changes in haiku, so some stuff you can enjoy already. (This affects the WASM memory protection bug, aswell as one for youtube playback based on private apis beeing linked in wrongly)
Personally Iâd want to make the release after fixing drawing of svg content and buttons when scrolling down the page. But then again there is always a ânextâ thing to fix that should surely be in the ânextâ one. ; )
(And that will probably /also/ be partially fixed by changes in haiku, so there is that)
1 Like
Maybe offtopic here, but: Its me? or webpositive is working much much better? including in youtube, appears to work more smooth⌠If we can correct the tearing when scroll (floating top bars) in the eyes of the average human it would look like a pretty polished browser !!!
5 Likes
Same here. Browsed the web for a couple of hours yesterday, and it is a lot smoother and more stable than it used to be a few weeks ago.
3 Likes
Well, the two major reasons WebKit would crash as of late were bugs in Haiku itself which were resolved on the nightlies in recent weeks (both by myself), so that would explain the increased stability.
Performance is somewhat more of an unknown. I made a number of changes to Haiku recently which were technically performance improvements, but they were all to things that I would not expect WebKit to use, as mentioned in a previous reply. It would be interesting to see benchmarks and whether or not WebKit really was using them, or something else entirely provided the apparent performance improvement.
14 Likes
Update: Haiku R1B3 x86 (hrev55181+66, GCC 11.2):
Haikuwebkit 1.8.4-devel
WebKit 614.1.6 (Ref: Fix skewed styled borders ¡ haiku/haikuwebkit@30f313d ¡ GitHub)
Stability testing Haiku R1B3 x86 (hrev55181+66) with Webkit 614.1.6
Checked:
Youtube: 
Gerrit (review.haiku-os.org):
Discuss forum:
Haiku website:
GMail:
Overall stability seems OK in comparison to Falkon/QTWebEngine on Haiku. Seems comparable in stability to WebPositive 1.2-alpha w/ HaikuWebkit 1.8.4/WebKit 613.1.10.
10 Likes
I posted a review a few months ago on gerrit to add support for loading fonts from memory as a step towards webfonts. Iâm sure there are more important issues to solve and it is a rather large/invasive review for people to wade through, but I hope itâll get integrated at some point. Then of course web+ would still need the changes to use that APIâŚbut itâs a step.
As I got a new laptop at the moment Iâm busy writing drivers⌠I will resume work on Web+ when I am able to use my wifi and trackpoint at least, as right now, travelling with that laptop is not a very great experience 
15 Likes