[GSOC 2024] Fix Haiku’s WebKit2 Port

Community
1

WebPositive is Haiku’s default browser, but it certainly has room for improvement. The goal of my GSoC project is to improve it.

WebPositive’s browser engine is WebKit. Currently, we’re stuck using WebKitLegacy, an older version of WebKit. Thanks to @Rajagopalan’s GSoC project, and @PulkoMandy’s work, we do have a partially working version of WebKit 2, the successor to WebKitLegacy. Currently, though, it can’t load webpages, and doubtless has various other problems. I hope to significantly improve it. And, maybe, hopefully, I can even get the changes integrated into WebPositive.

For those interested, my project proposal is below. It’s a bit short, because it’s hard to know beforehand will be involved in fixing WebKit 2, but hopefully, it’s sufficient. If you have any feedback, I’d be happy to hear it!

View project proposal

Fill-in-the-blank questions and Introduction have been redacted

Project Proposal

I want to work on getting Haiku WebKit’s webkit2 version working. My hope is to get MiniBrowser working well. If there is enough time remaining, I might also be able to get WebPositive to use webkit2.

Timeline

Naturally, getting a timeline is hard, since I’m not sure what will come up as I work on my project. But, here’s a rough approximation:

Community bonding period

  • Improve my tooling. Hopefully I can avoid 1-2 hour build times for just a small change. Also, I want to get a good editor setup, whether it is Genio, or Spacemacs, with a working jump to definition.
  • Interact with the community!

First month of coding

  • Get MiniBrowser working. This might look like getting a simple site like google.com to load.

Second month of coding

  • Fix the rough edges of MiniBrowser and Haiku WebKit. I believe that while getting MiniBrowser working, I’ll see plenty of problems with the code and various other things that should be fixed.

Third month of coding

  • If there’s enough time remaining after the other two tasks, I hope to integrate WebKit2 into WebPositive.

After Google Summer of Code

Maybe I’ll continue working on integrating WebKit2 into WebPositive. More likely, I won’t have enough time for such a large project and so take up a smaller one, such as continuing to work on Haiku-PyAPI.

Expectations from Mentors

In theory, I could likely do the entire project by myself. But that doesn’t necessarily mean it’s a good idea. I expect mentors to be useful in

  • Understanding the big picture
  • Understanding past decisions
  • Making sure my code is high-quality
  • Making sure that I’m going in the right direction
9 Likes
2

Webkitlegacy is not an older version of webkit, it is an API for webkit.

google.com is not a simple site at all.

A better target would be the webkit test suite, or something like the Haiku website.

The previous webkit2 attempt already had websites loading in any case.

3

Yes, I was aware that something like that was true :sweat_smile:. Makes me wonder whether my GSoC project will have an actual effect on how well WebPositive works or if it will just lay the foundation for future improvements.

Yes, that’s true. I was thinking “simple” for HaikuWebKit. For example, youtube is less “simple,” since WebPositive can’t even play videos currently.

4

Yes, but playing videos is a different issue entirely.

The main advantage for us is really the reliability.
One tab, or tab group, whatever is represented by a single process in the design, crashing will no longer crash or hang the entire browser. Another advantage is that some apis will likely be much easier or even become possible to enable, for example the adblocking api.

Edit: another bonus is that this will allow to redesign the api to add a webview into a BApplication, if this works with a normal BView this can then much easier be embedded into for example the mail application. Since we no longer need the BWebApplication (i think it is called? or BWebView?)

2 Likes
5

Thanks @Zardshard ,

I “collect” the available browsers on Haiku - now I could get this

Minibrowser

as well – installing webkit_gtk_demo.

> pkgman search mini
Status  Name                          Description                                                                               
--------------------------------------------------------------------------------------------------------------------------------
        diskus                        A minimal, fast alternative to 'du -sh'                                                   
        diskus_debuginfo              A minimal, fast alternative to 'du -sh' (debug info)                                      
        diskus_source                 A minimal, fast alternative to 'du -sh' (source files)                                    
        flashback                     Based on REminiscence REinforced                                                          
        flashback_source              Based on REminiscence REinforced (source files)                                           
        frei0r                        A minimalistic plugin API for video effects                                               
        frei0r_devel                  A minimalistic plugin API for video effects (development files)                           
        frei0r_source                 A minimalistic plugin API for video effects (source files)                                
        googlemaps_mini               Google Maps Mini                                                                          
        googlemaps_mini_source        Google Maps Mini (source files)                                                           
        hiredis                       A minimalistic C client library for the Redis                                             
        hiredis_devel                 A minimalistic C client library for the Redis (development files)                         
        hiredis_source                A minimalistic C client library for the Redis (source files)                              
        lagrange                      A Beautiful Gemini Client                                                                 
        lagrange_source               A Beautiful Gemini Client (source files)                                                  
        libdsm                        A minimalist implementation of a client library for SMB using C                           
        libdsm_debuginfo              A minimalist implementation of a client library for SMB using C (debug info)              
        libdsm_devel                  A minimalist implementation of a client library for SMB using C (development files)       
        libdsm_source                 A minimalist implementation of a client library for SMB using C (source files)            
        mbedtls_tools                 Open source, portable, easy to use, readable and flexible SSL library                     
        minicom                       A menu driven communications program                                                      
        minicom_source                A menu driven communications program (source files)                                       
        minimizeall                   Minimize all your apps with the press of a button!                                        
        minimizeall_source            Minimize all your apps with the press of a button! (source files)                         
        minipro                       An open source program for controlling the MiniPRO TL866xx programmers                    
        minipro_devel                 An open source program for controlling the MiniPRO TL866xx programmers (development files)
        minipro_source                An open source program for controlling the MiniPRO TL866xx programmers (source files)     
        minisign                      A dead simple tool to sign files and verify digital signatures                            
        minisign_source               A dead simple tool to sign files and verify digital signatures (source files)             
        miniupnpc                     UPnP IGD client lightweight library                                                       
        miniupnpc_devel               UPnP IGD client lightweight library (development files)                                   
        miniupnpc_source              UPnP IGD client lightweight library (source files)                                        
S       minizip                       Mini zip and unzip based on zlib                                                          
        minizip_devel                 Mini zip and unzip based on zlib (development files)                                      
        minizip_source                Mini zip and unzip based on zlib (source files)                                           
        mxml                          Minimum XML Library                                                                       
        mxml_debuginfo                Minimum XML Library (debug info)                                                          
        mxml_devel                    Minimum XML Library (development files)                                                   
        mxml_source                   Minimum XML Library (source files)                                                        
        netpbm                        Toolkit for manipulation of graphic images                                                
        pyserial_python310            Python serial port access library                                                         
        pyserial_python39             Python serial port access library                                                         
        qview                         Minimalist image viewer                                                                   
        qview_source                  Minimalist image viewer (source files)                                                    
        reminiscence_libretro         REminiscence, a port of the Flashback game engine to the Libretro API                     
        reminiscence_libretro_source  REminiscence, a port of the Flashback game engine to the Libretro API (source files)      
        texlive_latexextra            TeX Collection: LaTeX additional packages                                                 
        texlive_luatex                TeX Collection: LuaTeX packages                                                           
        texlive_metapost              TeX Collection: MetaPost and Metafont packages                                            
        texlive_pictures              TeX Collection: Graphics, pictures, diagrams                                              
        webkit_gtk_demo               Open source web browser engine (MiniBrowser demo)                                         
~> pkgman install webkit_gtk_demo
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (BeSly Software Solutions)...done.
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (FatElk_64)...done.
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (Haiku)...done.
100% repochecksum-1 [64 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (HaikuPorts)...done.
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (KapiX's Depot)...done.
100% repochecksum-1 [71 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (LOTE)...done.
The following changes will be made:
  in system:
    install package webkit_gtk_demo-2.40.0-1 from repository HaikuPorts
Continue? [yes/no] (yes) : 
100% webkit_gtk_demo-2.40.0-1-x86_64.hpkg [65.12 KiB]
Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta4/x86_64/current/packages/webkit_gtk_demo-2.40.0-1-x86_64.hpkg...done.
[system] Applying changes ...
[system] Changes applied. Old activation state backed up in "state_2024-03-25_18:08:40"
[system] Cleaning up ...
[system] Done.
~>

I know, it is with a different engine, but it is that browser, and a new browser for me :-p

Processing: MiniBrowser__WebKitGTK_version.png…

6

Yes,

WebKitLegacy is not an older version of WebKit, it is a different API to access the same engine. However, it is a much older API and is effectively unmaintained. This means a lot of the engine’s features are not exposed to the browser. Think of things like ad blockers, password managers, or even usage of gamepads for web gaming, that require some coordination with the frontend going through the API.

It also allows to run things in more separate threads. In the current WebKitLegacy system, the browser has to make sure to forward everything to its main process, each window thread cannot call directly into WebKit code or things will crash. The new API will also solve this for the browser frontend side.

And yet another way this will be beneficial: by using the API in a different way, we can see some problems in a different way and find a fix for them. This may also benefit the legacy version of the code.

3 Likes
7

The proposal as you submitted it here is very short. I think we expect something with a bit more details. Did you have a chance to investigate the current problems with MiniBrowser? Do you have some plans for a solution?

Did you do a review of in what state the project was back in 2019? From that, you can probably find the next steps after the immediate problem in the curernt code (setting up inter process communications) is fixed.

2 Likes
8

This link shows work done:

3 Likes
9

Thanks for the feedback! I’ve managed to significantly expand the project proposal section of my proposal. That section is now two pages long!

View updated project proposal

Fill-in-the-blank questions and Introduction have been redacted

Project Proposal

I want to work on getting Haiku WebKit’s webkit2 version working. My hope is to get MiniBrowser working well. And perhaps, if there is enough time remaining, I might also be able to get WebPositive to use webkit2.

Getting MiniBrowser working will involve a lot of work. I don’t know about all of the tasks involved yet, but here are some of the ones that may come up, in approximate order of importance:

  1. Fix inter-process communication.
  2. Make sure logs work.
  3. Make sure software rendering works.
  4. Make keyboard and mouse interactions work.
  5. Implement the web inspector.
  6. Improve the API exposed to Haiku applications.
  7. Clean up code.
  8. Implement miscellaneous platform-specific items, such as context menus, drag-and-drop, clipboard support, spell checking, full screen, and so on.
  9. Integrate WebKit 2 with WebPositive.

From what I can tell, doing all this is a massive endeavor, and I doubt I’ll be able to get through all of it by the end of GSoC. Therefore, I want to get the most important things first, leaving less important things for later. This would look something like:

  1. Get the basics working, like how they were at the end of GSoC 2019.
  2. Add some of the most important additional features, such as mouse and keyboard support.
  3. Fill out the rest of the features.

The Tasks

For those interested, here is a deeper dive into what I believe will be involved for each of the tasks listed above.

Fix inter-process communication (IPC)

This is currently the most important problem preventing things from working. Without the UIProcess, NetworkProcess, and WebProcess being able to communicate with each other, web pages cannot be loaded, let alone displayed! It also appears that this is keeping logging from working.

PulkoMandy has explained the problem relatively well in the blog post “So you want to help with webkit?”. Currently, we try to use BMessages and BLoopers for IPC. This seems possible, but has proven somewhat difficult to do. So, either we need to find a solution, or we need a good alternative method.

Make sure logs work

Logs are useful for debugging. Once IPC is working, it should be possible to make logging work, if it isn’t working already. Having logs will make debugging WebKit easier.

Make sure software rendering works

Software rendering is what will display the web pages to the screen! After fixing IPC, this may work just work. If not, then I’ll definitely want to fix it.

I’ve already done some work on this problem, so I have some idea of what is involved. The biggest problem is that WebKit is so focused on GPU rendering, that it almost completely ignores software rendering. This means the easiest way of rendering a web page may be through software OpenGL! Hopefully, it is possible to use a more efficient solution, like what WebKitLegacy uses.

Rajagopalan mentions in “GSOC 2019 final report” that some web pages, such as haiku-os.org displayed a white page. This problem may still be around and so may need to be investigated as well.

Make keyboard and mouse interactions work

This one is also mentioned in Rajagopalan’s final report. Some work has already been done on supporting the mouse, but the keyboard support remains largely missing.

Implement the web inspector

PulkoMandy has mentioned that having a web inspector may be useful for debugging. The inspector appears to need to interface with both the UIProcess and WebProcess to work. Currently, no platform-specific code has been written addressing this, and so I’ll be starting mostly from scratch.

Improve the API exposed to Haiku applications

We currently have a minimal API that MiniBrowser can use. This API should be filled out so that other applications, such as WebPositive, can use it as well. There are three potential approaches to this:

  1. Try to mirror WebKitLegacy’s API as closely as possible.
  2. Try to mirror an API of an existing platform, such as GTK, as closely as possible.
  3. Create a whole new API.

Clean up code

Some sections of the code are a mess. They could certainly be cleaned up.

Implement miscellaneous platform-specific items

This includes making sure that things like context menus, copy and paste, drag and drop, spell checking, and full screen work. All of these are likely relatively simple to implement.

Integrate WebKit 2 with WebPositive

The whole point of all of this!

Timeline

Naturally, getting a timeline is hard, since I’m not sure what will come up as I work on my project. But, here’s a rough approximation:

Community bonding period

  • Improve my tooling. Hopefully I can avoid 1-2 hour build times for just a small change. Also, I want to get a good editor setup, whether it is Genio, or Spacemacs, with a working LSP.
  • Interact with the community!

First month of coding

  • Get MiniBrowser working. This might look like getting a relatively simple site like google.com to load.

Second month of coding

  • Fix the rough edges of MiniBrowser and Haiku WebKit. I believe that while getting MiniBrowser working, I’ll see plenty of problems with the code and various other things that should be fixed.

Third month of coding

  • If there’s enough time remaining after the other two tasks, I hope to integrate WebKit2 into WebPositive.

After Google Summer of Code

Maybe I’ll continue working on integrating WebKit2 into WebPositive. More likely, I won’t have enough time for such a large project and so take up a smaller one, such as continuing to work on Haiku-PyAPI.

Expectations from Mentors

In theory, I could likely do the entire project by myself. But that doesn’t necessarily mean it’s a good idea. I expect mentors to be useful in

  • Understanding the big picture
  • Understanding past decisions
  • Making sure my code is high-quality
  • Making sure that I’m going in the right direction
1 Like
10

I guess you mean enable and fix it. We should use the same web inspector as Safari and webkitgtk if possible.

How do you figure that? WebkitGTK still uses cairo which is software rendered.
In any case: using OpenGL is an unaccpetable cost in my eyes, it would go from “use one core 10%” to spinning up all my cores for llvm .-.

11

Well, I wouldn’t be surprised if there’s a bit of that too, but there’s also things that need to be implemented in WebKit 2 for it to work.

Yes, I tend to agree that we should reuse as much as possible from them.

Hmm, you might be right. In fact webkit_gtk_demo can be run on Haiku and doesn’t have too bad of a performance.

12

Also, to add to this,
Apple does not use/support OpenGL on their platforms. Maybe they use Metal but I don’t know for sure.

The other port that Igalia maintains, webkit embedded, probably doesn’t need 3d acceleration either.

For the playstation port I have no idea to be honest.

Was a bit longer since i was in the slack for webkit, it seems my account or something is gone. (despite the snarky update logs slack keeps posting)

13

Did you try to compile Haiku WebKit2 yet?

Key areas to compile current build of WebKit2:

  • Fix Haiku’s RemoteNetworkingContextHaiku code for WebKit2.
  • Fix Haiku’s NetworkDataTaskHaiku code for WebKit2
  • Fix Haiku’s SharedMemoryHaiku code for WebKit2.
  • Fix Haiku’s IPCSemaphoreUnix code for WebKit2.

I’ve gotten it to build almost to completion on recent snapshots - but you’ll still need to review Haiku’s implementation code…

14

Apple officially uses Metal (still as of macOS Sonoma 14.4 (23E214)). Haiku utilizes Mesa/EGL in which you could get a working WebGL implementation. Well, down the road…

Note: Metal is kinda like Glide/Warp3D/TinyGL/Vulkan/etc. Since OpenGL is a spec itself, anything different of the OpenGL spec (i.e. features, functions, calls, etc) can’t be called “OpenGL” (and oh yes, the licensing issue thereof).

15

What has „official“ to do with anything?

The question is wether the macos, ipados, ios, tvos, watchos, visionos ports etc use metal.

16

Not necessarily. When there is nothing moving on screen (which is most of the time on a web browser), it should not use any CPU.

When there is something moving, it doesn’t need to render it at 600 frames per second and use all your CPUs for it. Note that in this context, OpenGL is not used to render everything, because, yes a web browser is mostly 2D (which is indeed done by Cairo). It is used to do the final steps of compositing several layers to render the final webpage. And it may be that this ends up being implemented faster by OpenGL than it would be by other means.

We had a short discussion with aperezdc (one of WebKitGTK maintainers), he says that on their side, OpenGL support is always compiled in, but can be switched on and off using a runtime flag.

It uses EGL and libepoxy. haikuwebkit/Source/cmake/OptionsWPE.cmake at haiku · haiku/haikuwebkit · GitHub so, yes, it does, at least for compiling.

17

Meaning, Apple states/stated Metal as their supported graphics API of choice for iPhone, iPad, Mac, Apple TV, Watch and Vision.

Maybe, this is useful to review Haiku’s implementation in the future… maybe not…

18

… Yes, obviously, it is their API. It has nothing to do with this discussion.

19

Strange, it seems I’ve managed to compile haikuwebkit without addressing any of these. I wonder how you’re building it? The current build I have is essentially a debug build (except I’ve modified most sections to compile as a release build with assertions enabled to save storage space). I did have to comment out some asserts that had syntax errors and haven’t committed these changes yet, and one or two other quick fixes of a similar nature. It compiles, and previous builds ran fine, just without actually displaying web pages. After some updates, running the latest build crashes from something related to IPC (which is not surprising. IPC hasn’t been working in haikuwebkit).

Ah, that’s a helpful summary. I was wondering why I kept seeing so much of hardware acceleration and Cairo.

20

cocobean is known to post very unreliable messages and pull requests. Don’t trust him too much.

The webkit2 code is of course compiling fine if you start from the current webkit2 branch and does not need any fixes to compile…