WebPositive rendering issues - text appearing and disappearing

[kallisti5]

Here's a good test candidate of the rendering issues in WebKit after haikuwebkit 1.8.1.

Compare:

• Otter Browser
• WebPositive

Test site:

• ​https://browserleaks.com/ssl

Notable issues:

• Text "disappears" when rendering.
• Even basic text that works will "disappear" when rapidly resizing window.

Reproduction:

• Load any content
• If text renders, resize window randomly
• Text disappears

[kallisti5]

basic example. On load

[kallisti5]

After resizing rapidly a bit.

[kallisti5]

text appearing and disappearing on load. Move movement over the window seems to make text appear and disappear.

[kallisti5]

I should mention, after the two fixes in #17062, I feel like this is happening slightly less often. It's still definitely happening, but it has improved somewhat.

[pulkomandy]

Rather easy to reproduce currently with ​https://webkit.org/code-style-guidelines

That page also tends to freeze app_server so I think I'll investigate that first.

[IIsi50MHz]

Suggest testing with different font settings in Appearance.

Anti-aliasing:

• Greyscale --> no observed faults
• LCD Subpixel --> some text disappears next time window is painted

Glyph hinting mode does not seem to affect result (except variable width typefaces have unrelated width change that should not happen, so I'll look for another related ticket).

[pulkomandy]

Interesting!

So, it's not the first time we have something like this. However, the previous ticket was closed with "seems to work now" and no explanation about what was fixed: #11114

Stippi gave some ideas however:

It does sound like the problem is very likely in the text rendering code path when there is an alpha mask.

It's quite possible that the issue was never fixed there, but WebKit was using alpha masks in less places. This could be confirmed by removing all calls to BeginLayer/EndLayer (​https://git.haiku-os.org/haiku/tree/headers/os/interface/View.h#n545) in WebKit sources.

[pulkomandy]

In my case I get disappearing text (on the webkit page) no matter which font settings are used.

[pulkomandy]

This seems to fix the problem: ​https://review.haiku-os.org/c/haiku/+/4207

However, I am not sure why this makes a difference.

[kallisti5]

It looks like this was a false positive. haikuwebkit has a habit of "randomly working" for bursts of time.

I built these changes into the R1/beta3 branch and master branch. Was able to reproduce the disappearing font issue in both cases on haiku-os.org

[nephele]

After the latest patch for haikuwebkit it is quite difficult to reproduce on webkit's blog site anymore.

I can still reproduce it relatively easily on ​https://discuss.haiku-os.org however

[nephele]

This seems to be specific to amd64, I haven't been able to test on my 32bit laptop yet.

Begasus mentioned on irc that this does not happen on their 32bit install but it does happen on 64bit.

[yann64]

Hope this is this is relevant to the bug hunting: in my case I can reproduce the bug on any discourse generated page, except if I enter an invalid URL.

I never managed to reproduce it on that "Ooops! That page doesn't exist or is private" 404 error page. And oddly the bug does not seem to happen for a few generated pages after I browse this 404 one (in fact, as long as I do not come back to the main/home page of discourse, so could it be specific to this page?).

If others can confirm it is not happening on their side browsing for the 404 page, I can try to generate static pages but with equivalent html/css/js as discourse generated ones to check if I can reproduce the issue, and then gradually remove css/js until I get similar css/js calls as the 404 one? Somewhere in between may be a hint of what is triggering the issue?

[nephele]

Nice find! I can reproduce the part that visiting the 404 site makes the issue much harder or not possible to reproduce on other sites (maybe for a set time?) I don't think that it caused by discourse initially though, because i can reproduce this in new sessions in HaikuLauncher without ever having visited discourse.

If others can confirm it is not happening on their side browsing for the 404 page, I can try to generate static pages but with equivalent html/css/js as discourse generated ones to check if I can reproduce the issue, and then gradually remove css/js until I get similar css/js calls as the 404 one? Somewhere in between may be a hint of what is triggering the issue?

Perhaps you can also strip down the 404 page to the smalest example that still inhibits the text issue so we may see which parts interact with each other to produce this?

[yann64]

I did some tests with nephele to narrow which css/js/html element can cause the issue, proceeding the following way: start from a midly simple html file causing the issue, and remove bits to find the guilty element.

Tests were done an old laptop (Intel display), with a new instance of WebPositive for each test (did not delete cache though as I do not know how to do it).

I started with ​http://barbel.synology.me/haiku/simple-1/ and finished at ​http://barbel.synology.me/haiku/simple-16/ , with the following modifications along the way:

• Simple-1 - Basic test -> bug
• Simple-2 - Remove inline svg -> bug
• Simple-3 - Remove inline css (but keep class references on css elements) -> bug
• Simple-4 - Remove css class references -> bug
• Simple-5 - Remove meta 'viewport' -> bug
• Simple-6 - Remove meta 'description' -> bug
• Simple-7 - Remove section 'main' -> bug
• Simple-8 - Remove div 'main-outlet' -> bug
• Simple-9 - Remove remaining/unnamed div -> bug
• Simple-10 - Remove meta charset 'utf8' -> bug
• Simple-11 - Remove h1 tags -> bug
• Simple-12 - remove lang=en -> bug
• Simple-13 - remove <!DOCTYPE html> -> bug
• Simple-14 - remove symbols (! and ') -> bug
• Simple-15 - completely remove head -> bug
• Simple-16 - just keep text (no html tags, no symbols, nothing else) -> bug

Conclusion: at least on my machine, HaikuWebkit will have the rendering issue even with a single line of text (no html tags, no css, to js)

All test are available at ​http://barbel.synology.me/haiku/simple-[1-16]/

[humdinger]

Another quick observation: For me (64bit) the text disappears (and actually also reappears sometimes) when moving the mouse over the Login/Logout etc. buttons at the top. Those highlight on mouse-over. It doesn't work necessarily on first mouse-over, but if I do it for a bit, text eventually dis/reappears.

[tqh]

How does z-indexes work in Webkit? Is it sorted by an unstable sort?

[pulkomandy]

There are no z-indexes and no sorting in any code we wrote. We just implement a few drawing commands (draw text, fill shape, etc), transforms, and drawing modes.

I think this issue could also be related to the "WebPositive never notices that downloads are finished" one. If WebKit is waiting for some resource to be downloaded and never get the completion notification, it may end up being stuck in an unfinished rendering state.

[nephele]

I think this issue could also be related to the "WebPositive never notices that downloads are finished" one. If WebKit is waiting for some resource to be downloaded and never get the completion notification, it may end up being stuck in an unfinished rendering state.

In that case the working of the 404 site may simply be the 404 error code that gets returned? maybe an issue in the new netservices api?

[pulkomandy]

Either in the API itself or in the way WebKit uses it, yes.

[pulkomandy]

Completing the loading is normally done here: ​https://github.com/haiku/haikuwebkit/blob/haiku/Source/WebCore/platform/network/haiku/BUrlProtocolHandler.cpp#L237

In WebPositive this will make the loading BStatusBar in the bottom of the window disappear. It should also be possible to see the corresponding log if you have built the network lib in debug mode.

[yann64]

If I come back to my single text line test:

• Loading seems to successfully finish and the message "​https://barbel.synology.me/haiku/simple-16/ finished" is indeed displayed in the status bar.
• Be then serious "wiggling" of the windows brings again the bug.

From this simple test:

• I cannot confirm that there is only partial loading as the root cause of the bug. Loading looks OK.
• Also, something I did not notice at first: the text is still there/loaded, it is simply becoming white (I can still select it as per screenshot I will attach after posting this).

[pulkomandy]

Also, something I did not notice at first: the text is still there/loaded

Yes, of course, if it wasn't there, the page layout would change much more dramatically since there would be no font metrics to compute the size of anything. Is is just a rendering problem, doing things in the wrong order or with an incorrect view state. But the layout side where WebKit decides where to put each element is working fine.

[nephele]

python3 -m http.server

and then trying ​http://localhost:8000/notfound gives me a page which i cannot reproduce the error with either, although sometimes i get "interupted system call" as an error instead of the page display, probably a different issue.

[madmax]

FWIW, I've added traces in GraphicsContextHaiku and a handful of other places, opened the simple ​https://barbel.synology.me/haiku/simple-16/ and resized the window like crazy until the text disappeared. This is repeated while the text is visible (all from GraphicsContextHaiku, except FontCascade::drawGlyphs):

ctor
save
translate 0 0
translate 0 0
clip (full view)
updateState
updateState
updateState blend mode = copy
fillRect (full view)
updateState blend mode = source-over
drawGlyphs @ 8 23
updateState
updateState
restore
dtor

When the text disappears, the drawGlyphs call is changed to translate 8 23, translate -8 -23.

I guess something somewhere should be blitting some buffer between the paired translate calls but doesn't or it does not contain the text or...?

[kallisti5]

In the interests of bisecting...

I was able to build haikuwebkit as of ​https://github.com/haiku/haikuwebkit/commit/c49d47d74e8356bd5412cffdcbfb3b049b87b58b with the dirty patch below.

The text disappearing issue *still* happens within HaikuLauncher as of this March 7th commit.

diff --git a/Source/WebCore/PlatformHaiku.cmake b/Source/WebCore/PlatformHaiku.cmake
index 162f59512c..8bb1a42269 100644
--- a/Source/WebCore/PlatformHaiku.cmake
+++ b/Source/WebCore/PlatformHaiku.cmake
@@ -15,6 +15,7 @@ list(APPEND WebCore_INCLUDE_DIRECTORIES
   "${WEBCORE_DIR}/platform/network/haiku"
   "${FORWARDING_HEADERS_DIR}/JavaScriptCore"
   "${CMAKE_SOURCE_DIR}/Source"
+  "/boot/system/develop/headers/private/netservices"
 )

 list(APPEND WebCore_SOURCES
@@ -307,6 +308,8 @@ if (ENABLE_WEB_AUDIO)
     add_definitions(-DUNINSTALLED_AUDIO_RESOURCES_DIR="${WEBCORE_DIR}/platform/audio/resources")
 endif ()

+add_definitions(-DLIBNETAPI_DEPRECATED)
+
 # Directory listing template for FTP/file/gopher directory listings.
 install(FILES "${WEBCORE_DIR}/platform/haiku/resources/Directory Listing Template.html"
     DESTINATION ${CMAKE_INSTALL_PREFIX}/${DATA_INSTALL_DIR})
diff --git a/Source/WebCore/platform/graphics/haiku/MediaPlayerPrivateHaiku.h b/Source/WebCore/platform/graphics/haiku/MediaPlayerPrivateHaiku.h
index 879f4bf339..af0510ec5c 100644
--- a/Source/WebCore/platform/graphics/haiku/MediaPlayerPrivateHaiku.h
+++ b/Source/WebCore/platform/graphics/haiku/MediaPlayerPrivateHaiku.h
@@ -19,6 +19,7 @@

 #ifndef MediaPlayerPrivateHaiku_h
 #define MediaPlayerPrivateHaiku_h
+
 #if ENABLE(VIDEO)

 #include "MediaPlayerPrivate.h"
diff --git a/Source/WebKitLegacy/haiku/WebCoreSupport/FrameNetworkingContextHaiku.h b/Source/WebKitLegacy/haiku/WebCoreSupport/FrameNetworkingContextHaiku.h
index 0384eda1e0..97317b7aee 100644
--- a/Source/WebKitLegacy/haiku/WebCoreSupport/FrameNetworkingContextHaiku.h
+++ b/Source/WebKitLegacy/haiku/WebCoreSupport/FrameNetworkingContextHaiku.h
@@ -29,6 +29,8 @@
 #ifndef FrameNetworkingContextHaiku_h
 #define FrameNetworkingContextHaiku_h

+#define LIBNETAPI_DEPRECATED 1
+
 #include "FrameNetworkingContext.h"

 #include <support/Locker.h>
diff --git a/Source/WebKitLegacy/haiku/WebCoreSupport/NotificationClientHaiku.cpp b/Source/WebKitLegacy/haiku/WebCoreSupport/NotificationClientHaiku.cpp
index 6a0a66dd97..1b0d8c7f9d 100644
--- a/Source/WebKitLegacy/haiku/WebCoreSupport/NotificationClientHaiku.cpp
+++ b/Source/WebKitLegacy/haiku/WebCoreSupport/NotificationClientHaiku.cpp
@@ -3,6 +3,7 @@
  * Distributed under terms of the MIT license.
  */

+#define LIBNETAPI_DEPRECATED 1

 #include "NotificationClientHaiku.h"

[madmax]

Replying to madmax:

When the text disappears, the drawGlyphs call is changed to translate 8 23, translate -8 -23.

That seems to come from ​TextPainter. I guess at some point we do have m_glyphDisplayList (set in TextPainter::setGlyphDisplayListIfNeeded), change to the replayer code and whatever WebKit has for that trips our way of drawing text?

[kallisti5]

I'm working on bisecting in parallel.

• R1/beta3 building haikuwebkit code as of march 1st (c49d47d74)
  • disappearing text confirmed
• R1/beta2 building haikuwebkit code as of march 1st (c49d47d74)
  • Will not compile. Missing posix functions (b3bd66961a)
• hrev54483 building haikuwebkit code as of march 1st (c49d47d74)
  • Compiling...

This bisect should play out like this:

• IF hrev54483 building haikuwebkit c49d47d74 works.
  • That shows it's a regression in Haiku's codebase between hrev54483 and HEAD
• IF hrev54483 building haikuwebkit c49d47d74 still has disappearing text.
  • haikuwebkit pre-c49d47d74 introduced the regression

[madmax]

I've closed my eyes, held my nose, taken an axe and reduced TextPainter::setGlyphDisplayListIfNeeded just to an unconditional TextPainter::removeGlyphDisplayList(run);. No more disappearing text. So at least we have the path where this occurs and even a kludge until someone gets to the root of it and comes with a proper solution.

That was with 1.8.2. Could someone that can already reliably trigger the problem and has a fast machine with tons of RAM compile that over current HEAD and test it?

[kallisti5]

My bisect is complete. hrev54483 building haikuwebkit c49d47d74 still has disappearing text.

Thus, the webkit regression was definitely introduced sometime before c49d47d74 in haikuwebkit.

I'll take a look at the workaround madmax mentioned now

[nephele]

Your workaround works for me, but I am not on HEAD of webkit but shortly after 1.8.2

[kallisti5]

workaround works for me too. NICE WORK MADMAX!!!!!

I'm packing these all up into a patchset for haikuwebkit-1.8.2

• font fix
• downloads not ending
• validation check
• darkmode

I plan on running one final test, then pushing that patchset to haikuports which will bump us to haikuwebkit-1.8.2-2

Then build packages... then RC1

[pulkomandy]

I think this is the correct fix: ​https://github.com/haiku/haikuwebkit/commit/bfc4c028ec945bd0ab2e16bde57943ab81af0a9b

Please confirm that it works if you can build WebKit by yourself.

(the hack-patch is fine for the release, it should work just as well).

Thanks for the help in investigating this and locating the problematic code path!

[madmax]

Replying to pulkomandy:

Please confirm that it works if you can build WebKit by yourself.

Confirmed (applied over 1.8.2, without the updates of the last few days).

[pulkomandy]

Temporary Fix backported to HaikuWebKit 1.8.2, more correct fix will be part of 1.8.3.