actually it’s like every crash on Haiku: a thread crashes and triggers the popup, the user has a chance to debug, kill, etc… if the thread isn’t critical (or was meant to die anyway), isn’t waited for, the process and the rendering will continue to work.
For people like me that don’t know enough about the development of web engines, at what stage of development is Falkon for Haiku in relation to Firefox and Chromium?
Falkon is available and working.
Chromium engine is working through QtWebEngine (what Falkon uses) but not directly available as the full Chromium browser.
Firefox depends on GTK+ what Haiku currently doesn’t support so it’s not available at all.
@nipos, so the engine used by Falkon is the equivalent of the latest Chrome version, i.e., Blink 98?
Chrome 83 from 2020-05-19.
2 Likes
Very good to know that @Diver. It’s not the latest but not too old.
Thank you.
Also, Qt 5.15.7 LTS uses 94.0.4606.81.
Recent active Chrome release: 96.0.4664.45
Falkon 3.1.0 shows Chrome 83.0.4103.122
1 Like
Fallon is definitely buggy though I’m glad it’s another web browsing option for Haiku.
It’s likely not Falkon fault but QtWebEngine port has some bugs which results in random crashes.
1 Like
Completely immature port pops up in the Depot.
Haiku users: It is not stable!
What did you guys expected?
3 Likes
Need fixes but GREAT!!! THANKS n,n
1 Like
I’ve just gave it a shot, but didn’t even start to build, it uses qt6, so Qt6WebChannel and Qt6WebEngineWidgets are missing, it looks like an interesting browser which seems feature-wise to be on par with qupzilla/falkon, hopefully someone will try to build qtwebengine with qt6, but it might turn out to be a bit of a work .
1 Like
It is definately the fastest browsing experience yet under Haiku (ignoring the stability). The Google v8 javascript parsing engine may be the reason why (just a guess). Once the stability improves, this will be a great addition to Haiku.
1 Like
Probably not. The main reasons for slowness in WebKit are first the drawing code, and second the network code. JavaScript is the least of our problems, and WebKit JIT is quite good (on 64bit systems at least, on 32bit it isn’t available anymore so a slower, but less memory intensive interpreter is used).
1 Like
I think QtWebEngine is a great bait to lure more contributors into Haiku. I love to see WebPositive succeed, but currently it is a real pain to use WebPositive after getting used to the performance level of browsers such as Safari. The non-ability to block content and slow network performance does not cut it for me at least.
It makes sense, but personally I’m a bit annoyed that a lot of effort went into Qt and QtWebKit then qwebengine that could maybe have been spent on native apps and haikuwebkit. So, yes, I know haikuwebkit needs more work, but it seems people put their work on something else instead. Not sure if that’s a good move or not.
Anyway, I will continue fixing bugs in haikuwebkit, there will be a new release this week fixing several crashing bugs and other problems…
14 Likes
I share your sentiment about this, I am also all for optimising and fixing native applications. However there is another catch; no matter how unique the platform is, having certain cross-platform applications and frameworks is also instant familiarity. For instance, having LibreOffice or Firefox on another obscure platform would make me consider switching, because it assures me that I can get stuff done on it. From this aspect, I believe it makes sense.
Your and other contributors’ work on Haiku WebKit is greatly appreciated, please continue doing so. Also as a personal wish, I’d like to see the net services overhaul merged as soon as possible so that I can start testing it.
5 Likes
Maybe it gets unnoticed, but running v8 test suites triggers Haiku bugs, and when they get fixed, it’s work on Haiku anyway. For instance https://git.haiku-os.org/haiku/commit/src/system?id=06a78d0d88cc041668aff2fe0e58032e4433d7ce
9 Likes
The net services overhaul is not complete and is extremely experimental. At present it will cause far more regressions than fixes because a lot of things are just not implemented. It is not at all ready for a merge, much less for testing.
2 Likes
Well, if you had mentioned that in the commit message, it might have gotten noticed more clearly. 
2 Likes