Fix building and running under Qt 6.5.3;

[quarcko]

Fix for QT_GESTURE_EVENTS Fix for TOUCH_EVENTS Fix in harfbuzz rendering engine crash

Not tested: Video, Audio, OpenGL (build without them)

Pull Request Template

File a Bug

All changes should be associated with a bug. The WebKit project is currently using Bugzilla as our bug tracker. Note that multiple changes may be associated with a single bug.

Provided Tooling

The WebKit Project strongly recommends contributors use Tools/Scripts/git-webkit to generate pull requests. See Setup and Contributing Code for how to do this.

Template

If a contributor wishes to file a pull request manually, the template is below. Manually-filed pull requests should contain their commit message as the pull request description, and their commit message should be formatted like the template below.

Additionally, the pull request should be mentioned on Bugzilla, labels applied to the pull request matching the component and version of the Bugzilla associated with the pull request and the pull request assigned to its author.

< bug title >
https://bugs.webkit.org/show_bug.cgi?id=#####

Reviewed by NOBODY (OOPS!).

Explanation of why this fixes the bug (OOPS!).

* path/changed.ext:
(function):
(class.function):

[aquiles2k]

@quarcko Hi, we are also trying to build webkit for Qt6. Do you have any build instructions you can share?

[quarcko]

@aquiles2k Hi, what Qt version and what OS are you on? I currently succeded to build it for Qt6.5.3 on Ubuntu 20.04 and 22.04. My plan was to test the source first on "easy" platform and i will move to building it on Windows with MINGW later on.

For Ubuntu: 1) Download webkit source and cmake-gui 2) Create "build" directory inside unpacked webkit source 3) open cmake-gui and select "source" and "build" directories appropriately 4) Run "configure" 5) cmake will periodically warn you that some libraries are missing, just "apt install" it after each warning i dont have a list and it depends on what you have 6) Configure then options what you want to include in webkit build 7) run generate 8) in terminal go to "build" directory and run make.

My repo and this commit contains fixes for actually building it and running.

OpenGL - is not found and unable to enable it Video and Audio suport - i disabled it as we dont need it at all DEVICE_ORIENTATION - does not compile, dont enable it. without my fix do not enable TOUCH_EVENTS and QT_GESTURE_EVENTS

thats it.

[aquiles2k]

@quarcko Thanks for sharing. We normally did a normal qt mac build with offical sources and just copied the annulen qt webkit binaries. We also did a crosscompile of qt and qt webkit for windows through mxe.

Since none of these worked anymore we were in the process of evaluating our options until we stumbled over the movableink fork. Its also very fortunate that it seems to compile with qt6 for you since webkit was the only thing holding us on qt5.

I'll try to reproduce your compile with ubuntu and from there move to mac and windows.

On your step 1, which source branch exactly do you use? Just the default master branch from movableink?

Thanks again and best wishes!

[quarcko]

We use qt6-gha branch. You can clone from my fork, so it will have all neecessary fixes to build it and run on ubuntu.

[mnutt]

@quarcko thank you for this! I'll merge it into my branch. I'm in a bit of limbo at the moment where I now use the qt6 branch myself in prod, but I want to get an actual qt5 release out before merging in the qt6 branch and dropping qt5 altogether.

[mnutt]

Re: OpenGL: I think it's quite a ways off from working. The QtWebKit OpenGL implementation was complex and is very, very behind. I run QtWebKit headless and I'm not likely to be able to work on OpenGL any time soon.

The other stuff seems like it should be feasible to get fixed up eventually.

[barolo]

Re: OpenGL: I think it's quite a ways off from working. The QtWebKit OpenGL implementation was complex and is very, very behind. I run QtWebKit headless and I'm not likely to be able to work on OpenGL any time soon.

The other stuff seems like it should be feasible to get fixed up eventually.

Hypothetically, wouldn't it be better at this point to skip OpenGL altogether and go straight to Vulkan which is fully supported [and working great] with Qt6?

[quarcko]

Hi,

I just mentioned OpenGL because cmake complained that it cannot find QtOpenGL libraries, so I am no big expert, and assumend it needs to be mentioned here. Actually i don't need it for my projects. We use webkit to render simple HTML forms and tables and print them to PDF (headless and GUI as well).

So this PR fixes building and running on Qt 6.5.3, but there are few issues though:

1) Mouse scroll wheel does not work (had no time to find a fix yet) 2) TOUCH_EVENTS - had no opportunity to test yet, we are still far from migrating fully to 6.5.3

Otherwise rendering and PDF printing is working all right.

[elahav]

@quarcko I am in the process of updating @mnutt code to the latest WebKit. I took a different approach in my git repository (https://github.com/elahav/WebKit), which has the main branch following upstream WebKit, and a qt6 branch for the updates. Once I get things working I want to start switching from WebKitLegacy, or there is no hope of getting anything upstreamed.

That said, as you seem to be actively maintaining a version of Qt webkit, we should probably join forces...

[quarcko]

@elahav Hi, it would be great, although i am not a very active webkit developer, we just migrate QT version now to 6.5.3 and i need working webkit for Ubuntu (already got it, but scroll wheel is not scrolling pages...) and Windows with MINGW (yes, MINGW is a requirement), so does your repo account for building with MINGW?

Because i managed to fix-through and compile movableink repo on WIndows MINGW 64bit - but unfortunately it crashes in LowLevelInterpreter.asm and here i am stuck for good, cause *.asm is not my cup of tea..

[elahav]

@quarcko I am not a WebKit developer either, and I'm really only interested in the QNX version as a good system-level test. But then between the two of us we cover three different platforms ;-) Hopefully @mnutt is still interested as well.

If we can make the switch from WebKitLegacy then we really only need to worry about the Qt bits. The rest will be upstream issues, and the developers are very responsive.

[mnutt]

I am! Glad to see other people are interested as well. I've been using qtwebkit/qt6 in production for a month and it has been working well for me so far.

My ambition is to get things to a point where qutebrowser/wkhtml2pdf/etc can get releases to replace the current ancient qtwebkit dependencies. Packaging has been a bit challenging and I haven't had as much time as I'd like to work on it.

Regarding WK2 - the things I use QtWebKit for don't benefit from it, but it'd be awesome if other people want to work on it. It looked like a huge amount of work to get working.

[elahav]

@mnutt First, thank you for the work on this port. I would have never started a Qt port from scratch (or even from the last official version). This gives us a fighting chance to get a working Qt browser that is not based on Chromium.

The reasons I want to switch to WK2 are two-fold:

1. Using WK1 means no support from upstream developers. They have moved on. I have no interest in fixing old bugs in old code, and the codebase is huge.
2. WK1 (as far as I can tell) receives no security updates. This means any product based on it will not be deployable in any environment other than a personal one.

All that said, I have no idea how much work such a switch entails.

[mnutt]

WK1 (as of now) is still part of upstream (the Mac port) and receives security updates. It may be removed in the future in which case we'd have to maintain it separately.

Not to say that WK1 couldn't have security issues, but the vast majority of CVEs I've seen have been in WebCore rather than WK2/WK1.

My application relies on pretty low-level integration into WK that is difficult to do performantly in WK2. But for general UI browsing, WK2 is way better: IPC reduces UI jank, and more importantly provides sandboxing. That would be the biggest reason to steer general users away from WK1.

[elahav]

OK, perhaps I misinterpreted the comments from the upstream developers. See

https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/

I may be confusing the variant (WK1 vs WK2) with the version.

By the way, apologies to @quarcko for appropriating this pull request for this discussion... We can move it elsewhere if you prefer.

[mnutt]

@quarcko this all looks good to me as far as I can tell, given that I don't have easy access to a Windows machine. Anything else needed here before merge?

Hopefully with moving to Qt6 it might be easier to get a Windows GitHub Actions setup going?

[mnutt]

Ah, I just saw https://github.com/movableink/webkit/issues/35. Happy to merge in a mostly-working windows version and merge future improvements as needed though.

[aquiles2k]

When configuring for msvc i get a cmake error in Source/WebKitLegacy/PlatformQt.cmake

I had to comment the code like the following to let it configure:

if (MSVC)
    #if (CMAKE_SIZEOF_VOID_P EQUAL 8)
    #    enable_language(ASM_MASM)
    #    list(APPEND WebKitLegacy_SOURCES
    #        win/Plugins/PaintHooks.asm
    #    )
    #endif ()

    list(APPEND WebKitLegacy_INCLUDE_DIRECTORIES
        ${DERIVED_SOURCES_WEBKIT_DIR}
    )

    #WEBKIT_ADD_PRECOMPILED_HEADER("WebKitWidgetsPrefix.h" "qt/WebKitWidgetsPrefix.cpp" WebKitWidgets_SOURCES)
endif ()

• win/Plugins/PaintHooks.asm isn't part of the buildsystem anymore since https://bugs.webkit.org/show_bug.cgi?id=226410
• cmake didn't know the WEBKIT_ADD_PRECOMPILED_HEADER macro

Is this the right approach?

[quarcko]

Here i found declaration of this macro, i can't tell you for sure if you have to comment this line, or maybe try to bring this MACRO to your sources and try what happens:

https://github.com/qtwebkit/qtwebkit/blob/a60f9b3b9fc5236496f278fdf9df4855f41aab0f/Source/cmake/WebKitMacros.cmake#L96

About non existing asm file - for now try to comment it out. you will figure out soon enough if thats a good solution when you try to run your webkit.

[aquiles2k]

Thanks @quarcko, i'm building with PCH disabled anyway for now.

It just seems im still miles away from a working msvc build. I thought msvc is the easy way 😄

Current error:

6>Target ClCompile:
6>  UnifiedSource-6cbc989f-1.cpp
6>  D:\Dev\Builds\qtwebkitcmakequarcko\JavaScriptCore\DerivedSources\yarr/YarrCanonicalizeUnicode.cpp(62,27): error C2370: 'JSC::Yarr::unicodeCharacterSetInfo': redefinition; different storage class
6>  D:\Dev\Sources\webkitquarcko\Source\JavaScriptCore\yarr\YarrCanonicalize.h(59): message : see declaration of 'JSC::Yarr::unicodeCharacterSetInfo'
6>  D:\Dev\Builds\qtwebkitcmakequarcko\JavaScriptCore\DerivedSources\yarr/YarrCanonicalizeUnicode.cpp(92,18): error C2370: 'JSC::Yarr::UNICODE_CANONICALIZATION_RANGES': redefinition; different storage class
6>  D:\Dev\Sources\webkitquarcko\Source\JavaScriptCore\yarr\YarrCanonicalize.h(58): message : see declaration of 'JSC::Yarr::UNICODE_CANONICALIZATION_RANGES'
6>  D:\Dev\Builds\qtwebkitcmakequarcko\JavaScriptCore\DerivedSources\yarr/YarrCanonicalizeUnicode.cpp(93,33): error C2370: 'JSC::Yarr::unicodeRangeInfo': redefinition; different storage class
6>  D:\Dev\Sources\webkitquarcko\Source\JavaScriptCore\yarr\YarrCanonicalize.h(60): message : see declaration of 'JSC::Yarr::unicodeRangeInfo'
6>  D:\Dev\Builds\qtwebkitcmakequarcko\JavaScriptCore\DerivedSources\yarr/YarrCanonicalizeUnicode.cpp(93,85): error C2078: too many initializers
6>  D:\Dev\Builds\qtwebkitcmakequarcko\JavaScriptCore\DerivedSources\yarr/YarrCanonicalizeUnicode.cpp(93,85): error C2131: expression did not evaluate to a constant
6>  D:\Dev\Builds\qtwebkitcmakequarcko\JavaScriptCore\DerivedSources\yarr/YarrCanonicalizeUnicode.cpp(93,85): message : a non-constant (sub-)expression was encountered
6>Done building target "ClCompile" in project "JavaScriptCore.vcxproj" -- FAILED.
6>
6>Done building project "JavaScriptCore.vcxproj" -- FAILED.
6>
6>Build FAILED.

It seems to have to do with the inspector so i'm trying to build now with web inspector ui disabled. Have anyone of you enabled this?

[aquiles2k]

Hm, no, disabling webinspector ui didnt fix it.

[quarcko]

FYI - i did not enable webinsperctor on both Linux and Mingw.

Anyway, (just curious) why do you need MSVC build anyway? Qt includes new WebEngine chrome-based which IS available with MSVC compiler.

[aquiles2k]

It's not msvc specific, i just need ANY working (modern) qtwebkit build since qtwebengine doesn't (yet) work with our project. We mainly use it to display a google map and rely heavily on painting stuff over it, which isn't possible with qtwebengine without a huge refactor.

We do try to do this refactor in parallel, but i'm also still trying to revive our qtwebkit component as a side project, since this would then be just a simple replacement without any refactor needed.

Mingw would be cool since our win build is using it currently but i'm not against msvc in general if it helps, but we would need to change our current ci infrastructure.

We are also still on qt5 which is why i'm trying compile the older code to prevent having also deal with qt6 issues in our app.

Unfortunately i'm still failing to have a "simple" working (displaying google maps) qtwebkit on any architecture.

BTW: @quarcko Do you have Webassembly enabled?

[quarcko]

Ok, clear on that. Let's hope you will manage it, MSVC is anyway a "supported" compiler :)

anyway - yes, i have webassembly enabled, JIT enabled, JSC enabled. My build is able to perfectly fine render amazon.com, ebay.com and other heavy sites.

Also - please have a look at my latest commit, is you have copied HarfBuzz fix from me before, it was heavily leaking memory and not working correctly. Now i included better solution there, although it's still not perfect.

[aquiles2k]

I fixed the above mentioned yarr errors by aligning some declarations and definitions with const and constexpr.

I'm now running into linker errors on jsc.exe

13>Target ClCompile:
13>  jsc.cpp
13>Target Link:
13>     Creating library D:/Dev/Builds/qtwebkitcmakequarcko/lib/Debug/jsc.lib and object D:/Dev/Builds/qtwebkitcmakequarcko/lib/Debug/jsc.exp
13>  JavaScriptCore.lib(UnifiedSource-6cbc989f-1.obj) : error LNK2001: unresolved external symbol currentStackPointer
13>  JavaScriptCore.lib(UnifiedSource-6cbc989f-2.obj) : error LNK2001: unresolved external symbol currentStackPointer
13>  WTF.lib(Threading.obj) : error LNK2001: unresolved external symbol currentStackPointer
13>  JavaScriptCore.lib(UnifiedSource-bfc896e1-12.obj) : error LNK2001: unresolved external symbol currentStackPointer
13>  JavaScriptCore.lib(Parser.obj) : error LNK2001: unresolved external symbol currentStackPointer
13>  JavaScriptCore.lib(UnifiedSource-3bec6ef2-1.obj) : error LNK2001: unresolved external symbol currentStackPointer
[...] and more

[quarcko]

Your stackpointer is defined here: Source/WTF/wtf/win/AsmStubsMSVC64.asm

Please check that this file is included in compilation and compiles. Also please look at /WTF/wtf/StackPointer.cpp

Where is says that currentStackPointer is defined in LowLevelInterpreter.asm on Win64