Opened 3 years ago
Closed 3 years ago
#17066 closed bug (fixed)
WebPositive rendering issues - text appearing and disappearing
Reported by: | kallisti5 | Owned by: | pulkomandy |
---|---|---|---|
Priority: | high | Milestone: | R1/beta3 |
Component: | Kits/Web Kit | Version: | R1/beta3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
Here's a good test candidate of the rendering issues in WebKit after haikuwebkit 1.8.1.
Compare:
- Otter Browser
- WebPositive
Test site:
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
Attachments (4)
Change History (36)
by , 3 years ago
by , 3 years ago
text appearing and disappearing on load. Move movement over the window seems to make text appear and disappear.
comment:1 by , 3 years ago
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.
comment:2 by , 3 years ago
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.
comment:3 by , 3 years ago
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).
comment:4 by , 3 years ago
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.
comment:5 by , 3 years ago
In my case I get disappearing text (on the webkit page) no matter which font settings are used.
comment:6 by , 3 years ago
This seems to fix the problem: https://review.haiku-os.org/c/haiku/+/4207
However, I am not sure why this makes a difference.
comment:7 by , 3 years ago
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
comment:8 by , 3 years ago
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
comment:9 by , 3 years ago
Platform: | All → x86-64 |
---|---|
Priority: | blocker → high |
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.
comment:10 by , 3 years ago
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?
comment:11 by , 3 years ago
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?
comment:12 by , 3 years ago
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]/
Which makes me wonder why no bug on Discourse 404 page. Probably some js make the page refresh the text display?
comment:13 by , 3 years ago
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.
comment:15 by , 3 years ago
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.
comment:16 by , 3 years ago
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?
comment:18 by , 3 years ago
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.
comment:19 by , 3 years ago
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).
by , 3 years ago
Attachment: | selected white text.png added |
---|
comment:20 by , 3 years ago
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.
comment:21 by , 3 years ago
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.
follow-up: 24 comment:22 by , 3 years ago
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...?
comment:23 by , 3 years ago
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"
comment:24 by , 3 years ago
Replying to madmax:
When the text disappears, the
drawGlyphs
call is changed totranslate 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?
comment:25 by , 3 years ago
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:
comment:26 by , 3 years ago
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?
comment:27 by , 3 years ago
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
comment:28 by , 3 years ago
Your workaround works for me, but I am not on HEAD of webkit but shortly after 1.8.2
comment:29 by , 3 years ago
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
follow-up: 31 comment:30 by , 3 years ago
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!
comment:31 by , 3 years ago
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).
comment:32 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Temporary Fix backported to HaikuWebKit 1.8.2, more correct fix will be part of 1.8.3.
basic example. On load