WebKit 613.1.1 - scrambled fonts on some pages

[vidrep]

hrev55402 x86_64

WebKit 613.1.1

Some pages display scrambled fonts. WebKit 612.1.21 not affected

Screenshot attached

[madmax]

B2IA messages have Ctrl-C characters in them.

I can't test it now, but this is probably due to an ​upstream change to make some control characters visible. The implementation changes them to the .notdef glyph, which is code 0. In our port that transforms into a NULL character that is not added to the string and we get characters and advances out of sync.

We could revert that or change the 0 (either there or in FontHaiku) for the replacement character, another non-character (that hopefully won't have a glyph and so come as .notdef), the white square (as was proposed when we had a similar problem before) or whatever. The same should be done wherever we return the advances.

[nephele]

With a debug build I hit an assertion.

~/proj/haikuwebkit-new/WebKitBuild/Debug ./HaikuLauncher                                                                             
Please note that you don't have secure memory on this system
ASSERTION FAILED: (*bitwise_cast<WTF::Config*>(&WebConfig::g_config[WTF::startSlotOfWTFConfig])).isThreadSuspendResumeSignalConfigured
../../Source/WTF/wtf/posix/ThreadingPOSIX.cpp(235) : static void WTF::Thread::initializeCurrentThreadEvenIfNonWTFCreated()
Abort

For completeness, this is what i changed to get Debug to compile:

diff --git a/Source/WebCore/testing/Internals.cpp b/Source/WebCore/testing/Internals.cpp
index ec2b92a8f5..f8091a2e16 100644
--- a/Source/WebCore/testing/Internals.cpp
+++ b/Source/WebCore/testing/Internals.cpp
@@ -6447,7 +6447,7 @@ constexpr TreeType convertType(Internals::TreeType type)
     case Internals::ComposedTree:
         return ComposedTree;
     }
-    ASSERT_NOT_REACHED();
+    //ASSERT_NOT_REACHED();
     return Tree;
 }
 
diff --git a/Source/WebKitLegacy/haiku/API/WebPage.cpp b/Source/WebKitLegacy/haiku/API/WebPage.cpp
index 3c37295f9b..954a183921 100644
--- a/Source/WebKitLegacy/haiku/API/WebPage.cpp
+++ b/Source/WebKitLegacy/haiku/API/WebPage.cpp
@@ -171,7 +171,7 @@ BMessenger BWebPage::sDownloadListener;
        // NOTE: This needs to be called when the BApplication is ready.
        // It won't work as static initialization.
 #if !LOG_DISABLED
-    WebCore::initializeLogChannelsIfNecessary();
+    //WebCore::initializeLogChannelsIfNecessary();
 #endif
     PlatformStrategiesHaiku::initialize();
 
diff --git a/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp b/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp
index 14eef5f5c6..196758c96e 100644
--- a/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp
+++ b/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp
@@ -1693,7 +1693,7 @@ inline void readySQLiteStatement(std::unique_ptr<SQLiteStatement>& statement, SQ
     if (!statement) {
         auto temp = db.prepareHeapStatement(str);
         if (!statement)
-            LOG_ERROR("Preparing statement %s failed", str.ascii().data());
+            LOG_ERROR("Preparing statement %s failed", str.characters());
         else
             statement = temp.value().moveToUniquePtr();
     }

[madmax]

One possible fix: ​https://github.com/haiku/haikuwebkit/pull/6

[pulkomandy]

The fix is merged, this will be part of the next webkit release.