Haiku WebKit port patchset

When ever I try to update something I always check if there is at least a test suite, this should be done always IMHO, lighttpd isn’t widely used in Haiku, but if there is some blocker it should be looked into before bumping a version (just added the wip label to the PR for lighttpd earlier until is sorted out)

Update for Oct 7, 2020:
Forked Master: Merged with Webkit-master (->2020-10-07, Webkit 611.1.1).
Both Webkit1 and Webkit2 were updated. :+1:
Ran Webkit tests for Webkit1. Only 1 test failed for Perl. Reviewing Ruby testing issue.

NOTE: Webkit2 (forked) was updated to Webkit 611.1.1. Requires further review and testing.

6 Likes

Forgive me, but is this a changelog for whats included in Nightly or something else?

Just tracking progress of successful merges between Webkit-master and Haiku-webkit branches.
Up to Webkit 611.1.4 now… :wink:

1 Like

Does that mean we are running 611.1.4 now?

webpositve-611.1.4_haiku-inc_cocobean
A few people are testing Webkit/Web+ over on IRC if you’d like to keep up-to-date on the latest status.

Update 2020-10-20: Haiku-webkit was recently updated to Webkit 611.1.4. I reforked haiku-webkit and bumped my fork up to Webkit 611.1.5 for Webkit-legacy and Webkit2.

Basic Tests using haiku-webkit (Webkit 611.1.4): Updated: 2020-10-25
Perl: PASSED all ‘expected’ tests. Failed 1 expected test.
Ruby: 2/2 tests failed.
Python3: Ran 1942 tests, failures=4, errors=12). Failures due to Linux/other-specific conditions.

Is all this available on HaikuDepot?

The test was from the current haiku-webkit built from the github repo.

No, they arent.

They aren’t for two reasons:

  1. The code cocobean submitted to me does not compile, so I don’t know what to do with it
  2. The current source of haikuwebkit uses some features that are only available in Haiku nightlies, so it cannot be compiled by the package automatic builder (which runs on beta2).

I am keeping the webkit port up to date on my own, and we will ship the update at the same time as beta3 or a short time before it as we update the builders and it’s possible to release it.

3 Likes

I cancelled that. Pushed things to WebKit 611.1.5 and a FFmpeg 4.3.1 build.

  • All media playback works with Youtube and reported media test sites with FFmpeg now.
  • Haiku MediaPlayer patch needs a tweak for Webkit 611.1.5.

Currently, I mostly use Web+ for basic web browsing and in-browser media playback so following Haiku VLC port on in-browser MediaPlayer control management (i.e. video frame slider control). There was some tweak I did for better font management/rendering with the Haiku Web+ font controller patch…

Some of the live news/streaming movie sites use plug-in media technologies…so that is another twister…

5 Likes

Latest WebKit version (https://github.com/haiku/webkit/commit/cdeafd299ccc47e6f605831552a044daf5690d02) is not working for me, it show page loading forever and nothing get loaded. Is it the same for others or I am doing something wrong? Maybe https://github.com/haiku/webkit/pull/35 is required?

Sorry, it was broken libbnetapi.so. It requires separate build for libbe_test that is not included in default install-test-apps target. Now it works fine.

3 Likes

Updated 2021-Jan-09:

Webkit unit testing using an updated forked haiku-webkit (Webkit 611.1.10) on Haiku hrev54858:
Perl: PASSED all expected tests based on previous testing. 
Python3: PASSED all expected tests.

Again, Webkit 611.1.10 unit testing passes as I expected on Haiku.

Happy New Year!

3 Likes

Note that these particular tests only check the perl and python infrastructure needed to build WebKit, and nothing about the browser itself.

There is a new WIP repo for the haiku webkit port at:

It’s currently still missing the gsoc2019 webkit2 code though

1 Like

Is it a rebase of Haiku patches over upstream WebKit that I suggested? Is it working? Haiku-specific changes commit history seems to be lost.

Yes, WebKit completely rewrote their commit history, so we cannot preserve the changes without a ton of hasstle, so we will just keep the “old” repository around in case we need the history. I imagine we will probably not, though.

Agreed. Kallisti5 provided a big commit of all the legendary porting work. A true masterstroke.
Bumped my fork to Webkit 611.1.10-latest and retained all of the ancient Haiku Webkit port history…

To be precise, the eqrly work (before 2014) on HaikuWebkit had already been upstreamed, and then deleted from upstream, and that part is still in their history.

The work since 2014 started with a big “reintroduce all Haiku things” commit anyway, and then is 6 years of mostly merge commits with upstream, and me removing and re-adding things and moving them around.

It is not a great and readable commit history to use as a reference.

Now that there are more people working on webkit (nephele, X512 and kallisti5), I may use my WebKit time to work on upstreaming things again (or anyone else could, really) as we have a large enough team to make sure we can keep things reasonbly in sync with upstream and they will not decide to remove our port again.

5 Likes