Chromium (Google Chrome) on Haiku?

Software
21

@PulkoMandy can correct me if I’m wrong here, but the biggest issue with porting Blink in particular is we would need to have hardware acceleration running for those OpenGL surfaces to work as afaik there is a requirement for desktop compositing there.
It’s afaik one of the big blockers for a number of pieces of software is the lack of a 3d compositing layer in userland above and beyond what bits of mesa are ported and running.

Porting Chromium/FireFox would also require porting a non-trivial number of libraries as well which is another nice big blocker :slight_smile:

22

It would be possible to port Blink using software OpenGL, why not? It would just be slow.

Desktop compositing is completely unrelated, and is linked only to the way app_server manages different applications drawing to the same display. There is no reason at all a web browser would be concerned with that.

There is no “biggest issue” with porting Blink as long as no one has tried and hit a difficult to solve problem. My guess would be the lack of a libuv port, which in turn means the lack of an appropriate API to implement libuv in an efficient way on Haiku. And that would only be the first step to getting the javascript engine running.

4 Likes
23

As I said, i was compiling Node JS (v8, libuv, openssl, etc) on x86 arch on Haiku.

I have succesfully created a obviously experimental binary of Node, by implementing most missing headers and functions as dummy code on a separate file (i.e. placeholders) and showing params on stdout to see what goes on.

Apart from some tweaking on includes not existing in Haiku , all the code that prevents libuv from working compiling seems to be some defines and the epoll backend, which could be implemented as you said above and in other threads, using some custom library like kqueue, native code or whatever is required to.
I know it wouldnt be performant as a native kernel solution, but having a working prototype to play with is feasible, it being standalone, part of node or whatever usage that may appear.

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-pc-haiku"...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /boot/home/Desktop/p/node-master/out/Release/node]

(gdb) run
Starting program: /boot/home/Desktop/p/node-master/out/Release/node
Error while mapping shared library sections:
commpage: No such file or directory.
Error while reading shared library symbols:
commpage: No such file or directory.
[WARNING][UNIMPLEMENTED][epoll_create1] params=> flags: 524288
[WARNING][UNIMPLEMENTED][epoll_create1] params=> flags: 524288
[WARNING][UNIMPLEMENTED][epoll_create1] params=> flags: 524288
[WARNING][UNIMPLEMENTED][epoll_ctl] params=> epfd: 0, op 1, fd 16 event 1892911284
[WARNING][UNIMPLEMENTED][epoll_ctl] params=> epfd: 0, op 1, fd 18 event 1892911284
[WARNING][UNIMPLEMENTED][epoll_pwait] params=> epfd 0, events, 1892911296 maxevents 1024, timeout -1, sigmask 0
node: ../deps/uv/src/unix/linux-core.c:291:uv__io_poll: timeout != -1
Thread 2941 called debugger(): timeout != -1

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to team /boot/home/Desktop/p/node-master/out/Release/node (2939) thread pthread func (2941)]
0x69931114 in ?? ()
(gdb)

Yes i know this is hacky code, nothing more than a toy. Just giving my 2 cents.

Also, found some troubles at Haiku missing getpriority / setpriority methods, that are required by the code. I see that there is a pending change to implement them (by yourself?) here https://dev.haiku-os.org/ticket/2817 but i guess that the implementation is not yet in the “almost rc1” system i’m on. Please if i’m wrong with this, tell me about it.

1 Like
24

Check the libuv pr at haikuports.

1 Like
25

Oh good. Thanks for the tip. I will play a bit more with that and my node toy version :thinking:

1 Like
26

The feature that makes Chromium or Firefox so desireable is extensions. My daily routine uses three Chrome extensions and occasionally a couple of others.

Oh, yes, they also store passwords, so I don’t have to type in the login for this forum each time, for example. :slight_smile:

Later: I’m now using Qupzillla for Gmail. I plan to try Gmail with the Mail app.

27

Well, maybe rebrand Web+ to Chromiu+ or Firefo+. :wink:

28

The problem is that most people leaved the chains of IE explorer toward Firefox in the 00’s and later Chrome/Opera/other , you spent time working and bitching about it, and have long time using it.

Apart from the Haiku traditional users, most newcomers will try to look for known ground.

I know I instantly skip native browsers (IE/edge, safari and “midori”) on every OS and install firefox asap as the OS is installed (because i prefer the bad mozilla overlords vs google worse ones).

I used web+ in native haiku installation tho, but after some pages werent working 100% (this forums Reply popup window for example), i went to QupZilla.

1 Like
29

It’s always a mix for me. QupZilla doesn’t work well with the github website, for example. I almost always use Web+, even if the icons in this forum are missing, there are still tool tips that help me feel my way around (mouse+tooltips on invisble icons must be a bit like reading braille… :slight_smile: )

I use QupZilla at the Haiku Depot Server site to upload screenshots that doesn’t work with Web+.

Edit: I just retried QupZilla and the Gmail site and now it seems to work fine. I probably used to try with an older version…

30

So uh, any progress on this or modern FF? Would be nice to have a web browser where websites don’t break in parts due to not having good support for the Webkit available in Haiku right now (looking at you GitHub). Also, Chrome-only websites and those only supporting recent Chrome and Firefox versions have begun to appear.

31

Try to ping the FF/Chrome folks to port their stuff to Haiku or dive in porting it :slight_smile:

1 Like
32

about extensions, it could be possible to implement the WebExtensions API used by FF, Edge and Chrome althoug the spec[1] for it is still a draft

[1] https://browserext.github.io/browserext/

33

Extensions for WebPositive will be compatible with the ones used by Safari and Epiphany. But we need more people working on the WebKit port.

1 Like
34

Do Safari and Epiphany still support traditional extensions? For Safari, it’s no longer the case:

Only thing I found about Epiphany’s extension support is about it not needing to have them:
https://wiki.gnome.org/Apps/Web/

No fumbling around to install extra extensions. Essential features like ad blocking that are relegated to extensions by other browsers come built-in and enabled by default in Web.

35

“traditional” extensions (NPAPI plugins) are still supported but will be removed (this was used for Flash back in the days). WebExtensions can be implemented (it does not necessarily need a lot of support from the engine).

Which extensions would you like to run? Anything besides the adblocker that can’t be done directly in the browser itself?

36

Besides the adblocker? Dark Reader and Windscribe VPN extension. Although to be honest, uBlock Origin is the top priority for me.

37

Please stop repeating this every time this request comes up.

First, FF/Chrome people won’t port their browser to Haiku, just as Blender or LibreOffice people haven’t - the Haiku people did that.

Second, judging by the fact that it isn’t ported already, it seems to be an extremly difficult task, for which the most forum users may not be qualified.

On the other hand, if someone with the proper skills starts the Firefox-Haiku porting project (in a separate git repo maybe?), I would happily polish my beginner coding powers on it. :smile:

2 Likes
38

Why not? And who should do the dirty job for them? And who is better situated to do it well than the original authors?

39

For ad-blocking, another solution that works (for all browsers) is blocking from the hosts file, for example using this:

Mozilla and Google porting and maintaining their browsers is what should happen, still. A browser engine is a larger codebase than the whole of Haiku, and Haiku developers already have a lot to do.

So, when we work on porting a browser, we make choices in line with the way we want things to be. For us, this means WebKit, the only engine that can be integrated tightly with our APIs and used by native applications. We will not put efforts in Firefox or Chrome. And even for WebKit we don’t have enough manpower (it’s largely me just trying to keep it up to date with upstream, and having no time for adding any new features to our port).

40

Using the hosts file leaves distracting empty spaces in webpages where ads should be. uBO blocks ads in a way that they don’t get loaded at all, eliminating those spaces.