Notes are invisible unless in note edit mode (ctrl-n)

[Dettorer]

Expected Behaviour

Notes are visible without having to press ctrl-n to enter note edit mode (when there are already some notes saved for that slide)

Actual Behaviour

Screenshots of each steps in "Steps to reproduce":

2. (blinking cursor bar present but not shown because the window is out of focus for the screenshot tool to work)

3. (blinking cursor bar still present but not shown for the same reason)

4.

5. (cursor bar still there)

Steps to reproduce

1. open the pdfpc demo PDF file (or any PDF file) with pdfpc
2. hit ctrl-n to enter note edit mode
3. write some text
4. hit escape to leave note edit mode
5. (hit ctrl-n to enter note edit mode again and confirm that the text written in step 3 is still there)

If I mouseover the notes region, I see my mouse cursor changing shape in a coherent way with the text that should be displayed (and even with the markdown formatting, if I put a link like in my "Actual Behaviour" example, my mouse cursor changes shape to a clickable indicator when it is over the region where the link should have been rendered). I guess this means that the notes are there, but not visible due to a coloring problem? If I try to select some text though, I don't see any visual indication that anything was selected (other than my mouse cursor changing shape in a coherent manner).

I usually use the Arc-dark GTK theme, I tried forcing my theme back to Adwaita (either by changing .config/gtk-3.0/settings.ini or by using GTK_THEME=Adwaita pdfpc, confirmed the theme change was effective by launching evince and checking its colors) but it didn't change anything.

(probably not useful information, but if then close pdfpc and re-open it on the same file, the notes are still not visible, and hitting ctrl-n to enter note edit mode shows me that the notes are still there and were correctly saved, they just aren't displayed unless in note edit mode.)

pdfpc version: pdfpc v4.6
Used Distribution (GTK version, Vala version): Archlinux (GTK 2.24.33, 3.24.41 and 4.14.2 installed, Vala was not installed, I tried installing my distribution's version, 0.56.16, no changes)
Display Server (X11/Wayland): X11
HiDPI Setting (yes/no): yes

(everything works fine on an other computer that is running nixos)

[fnevgeny]

Same as #703. Supposedly, resolved by updating the distro.

[Dettorer]

Hi, thank you for your answer!

I should have mentioned that in my description, sorry, but I already found #703 and tried to follow the leads it has, it looks like the exact same problem indeed. I update my system regularly, I did it again just now to double check but it didn't solve the problem. The only other lead that yangwenbo99 mentions is that it's "due to dependencies" and that it may be related to webkit2gtk, but I have no idea how this dependency might trigger the issue or what other dependency might be responsible and how.

My guess was a GTK coloring problem, probably linked to my bad decision of changing the default GTK theme, but I can't find a way to change that in a way that is visible inside pdfpc. I can try building pdfpc from source and tweak a few things to troubleshoot this further, do you have some indication (even vague) on where in the code I could change the color that pdfpc tries to display the notes with?

[fnevgeny]

Well, it very much sounds like a CSS-related issue. I just cannot imagine what may actually override the settings. Try tinkering with notes.css (probably installed in /usr/share/pdfpc/css/). You'll see there

body {
    font-family: Verdana, Helvetica, Arial, sans-serif;
    font-size: 20pt;
    background-color: black;
    color: white;
}

Basically, color: white is what somehow gets ignored or overridden. Perhaps try appending !important, like white!important.

[Dettorer]

Changing the colors doesn't seem to change anything (notes still invisible, and still white on black in edit mode). But if I add display: none to the body style, then my mouse cursor stops changing shape when I hover text and links, so that CSS file is correctly read by pdfpc and can influence things, just not the colors (at least not in that way).

Trying to build from source, I also realize that archlinux's packaging of pdfpc manually pulls discount 2.2.7d because of a build error with the (archlinux packaged) 3.0.0.d version, could the issue come from that direction? Is pdfpc built with a particular version of discount in mind?

[fnevgeny]

Changing the colors doesn't seem to change anything (notes still invisible,

Even the background?

and still white on black in edit mode).

In the edit mode, a different (not webkit2gtk) widget is used, so it doesn't say anything.

But if I add display: none to the body style, then my mouse cursor stops changing shape when I hover text and links, so that CSS file is correctly read by pdfpc and can influence things, just not the colors (at least not in that way).

Well, that's the puzzle. And I cannot reproduce it (even though tried the distributions mentioned in #703 - albeit in a VM).

Trying to build from source, I also realize that archlinux's packaging of pdfpc manually pulls discount 2.2.7d because of a build error with the (archlinux packaged) 3.0.0.d version, could the issue come from that direction? Is pdfpc built with a particular version of discount in mind?

discount is irrelevant. It's webkit2gtk that renders the notes. And so, installing pdfpc from the sources shouldn't make any difference. You may endeavor to compile webkit2gtk from sources, though - if you feel brave enough for that... Or try asking their developers for a hint. Again, I cannot reproduce the issue, so you or somebody else experiencing the problem should do it.

[Dettorer]

Changing the colors doesn't seem to change anything (notes still invisible,

Even the background?

Yes.

and still white on black in edit mode).

In the edit mode, a different (not web2gtk) widget is used, so it doesn't say anything.
[…]
discount is irrelevant. It's web2gtk that renders the notes.

Ok thanks, I'll see if I can find anything in that direction.

And so, installing pdfpc from the sources shouldn't make any difference. You may endeavor to compile web2gtk from sources, though - if you feel brave enough for that... Or try asking their developers for a hint. Again, I cannot reproduce the issue, so you or somebody else experiencing the problem should do it.

Perfectly understandable. And the issue does seem to come from something outside of pdfpc itself, I'll keep looking. Do you mind if I keep asking some questions here when I need to understand how pdfpc works or uses its dependencies? I'll try to keep those questions focused on what pdfpc is doing, but I'd understand if you still say no to that.

[fnevgeny]

Do you mind if I keep asking some questions here when I need to understand how pdfpc works or uses its dependencies?

No problem, of course.

[fnevgeny]

BTW, which version of webkit2gtk is installed in your case?

[Dettorer]

That's the 2.44.1 version.

[fnevgeny]

That's the 2.44.1 version.

?? Weird... Should be 4.0-something.

[fnevgeny]

Nevermind. It seems different distributions use different numeration schemes for the package.

[Dettorer]

Ok the version information on that package is weird. On archlinux we have two different packages:

• webkit2gtk (current version 2.44.1)
• webkit2gtk-4.1 (current version 2.44.1)

The two packages (base 4.0 and 4.1) don't seem to differ in any obviously meaningful way, they just use a different libsoup version (soup2 for the first one, soup3 for the second), but otherwise build exactly the same and from the same upstream version.

Anyhow, the first one is the default one and is the one marked as a dependency in pdfpc's package description.

[fnevgeny]

Just out of curiosity - please compile https://github.com/craigbarnes/showdown . Does it render an .md file correctly?

[Dettorer]

I compiled showdown successfully, although with the same warning I got from trying to compile pdfpc with the (archlinux) default discount 3.0.0:

showdown compilation warnings

$ make UPDATE build/version.txt GEN build/version.vala RESGEN build/resources.c UPDATE build/flags.txt VALAC showdown /home/dettorer/work/showdown/src/window.vala.c: In function ‘markdown_parse’: /home/dettorer/work/showdown/src/window.vala.c:565:50: warning: passing argument 3 of ‘mkd3_string’ makes pointer from integer without a cast [-Wint-conversion] 565 | _tmp0_ = mkd_string (text, text_length1, flags); | ^~~~~ | | | gint {aka int} In file included from /home/dettorer/work/showdown/src/window.vala.c:13: /usr/include/mkdio.h:78:35: note: expected ‘mkd_flag_t *’ {aka ‘void *’} but argument is of type ‘gint’ {aka ‘int’} 78 | MMIOT *mkd_string(const char*,int,mkd_flag_t*); /* assemble input from a buffer */ | ^~~~~~~~~~~ /home/dettorer/work/showdown/src/window.vala.c:567:32: warning: passing argument 2 of ‘mkd3_compile’ makes pointer from integer without a cast [-Wint-conversion] 567 | mkd_compile (document, flags); | ^~~~~ | | | gint {aka int} /usr/include/mkdio.h:93:25: note: expected ‘mkd_flag_t *’ {aka ‘void *’} but argument is of type ‘gint’ {aka ‘int’} 93 | int mkd_compile(MMIOT*, mkd_flag_t*); | ^~~~~~~~~~~

But then it segfaults somewhere in libmarkdown (so, discount) when trying to render something.

If I uninstall the discount version installed with my package manager, and install a version built from its 2.2.7d github tarball (the last 2.x version, which is used for building the pdfpc package on archlinux), then it compiles without warning and doesn't segfault, but I have the exact same rendering problem as with pdfpc's notes (no rendered text shows, but my mouse's cursor changes shape in a coherent manner as I hover it where the rendered text should be):

Exactly the same result if I build discount from the tarball for version 2.1.7 (the minimum version indicated in showdown's README).

EDIT: also tried installing the AUR (non-official archlinux community packages) version of showdown instead of compiling it myself, it builds with warnings and segfaults when used :D (but that package hasn't been updated since 2018 and blindly follows upstream's main branch, so it's not really relevant)

[fnevgeny]

OK, it all makes sense (that is, the same problem of the rendered text not visible). It might be something deeper than CSS. Please also try https://wiki.gnome.org/Projects/Vala/WebKitSample .

[Dettorer]

Indeed, same problem again (nothing displays but mouse cursor suggests that the content is here):

(same with --pkg webkit2gtk-4.1 FWIW)

[fnevgeny]

Great. Well, my last suggestion would be to try an equivalent in C, https://wiki.gnome.org/Projects/WebKitGtk/ProgrammingGuide/Tutorial. Compile it with something like

gcc `pkg-config --cflags gtk+-3.0  webkit2gtk-4.0` webkit-sample.c `pkg-config --libs gtk+-3.0  webkit2gtk-4.0`

Assuming it shows the same problem, you'll have an "official" GTK sample not working as expected - so please file a bug against webkit2gtk.

BTW, try blindly selecting a portion of the page (or its entirety, Ctrl+A) and drag it with the mouse around. Will it become visible?

[fnevgeny]

OK, I've managed to find a computer with this problem appearing. There is an NVidia card with the nouveau driver enabled. There are a bunch of dmesg's like

[Wed May  8 17:18:07 2024] nouveau 0000:01:00.0: gr: DATA_ERROR 0000009c [] ch 16 [017f4cb000 WebKitWebProces[4010487]] subc 0 class c597 mthd 0d78 data 00000004

Changing the driver to the proprietary one fixes the problem visually. However, there is still a hardware error upon each invocation of the WebKit widget:

[Wed May  8 19:13:21 2024] [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership

According to NVidia, it's an indication of an application misbehaving. So apparently, WebKit is doing something finicky.

What's your video hardware (and driver)?

[Dettorer]

Alright, so, the C webkitgtk example you suggested indeed triggered the same issue. I indeed have a nvidia GPU, but I'm already using the proprietary driver and I don't see any dmesg error.

However, I noticed every program that has had the issue so far print similar errors when they launch:

src/nv_gbm.c:288: GBM-DRV error (nv_gbm_create_device_native): nv_common_gbm_create_device failed (ret=-1)

KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 800x600: Permission denied

I googled those and found this gentoo forum post speaking about this exact issue with someone suggesting setting WEBKIT_DISABLE_DMABUF_RENDERER=1 before running the affected programs.

I can confirm that it works for me as it does for them: the examples, pdfpc notes, everything displays correctly now!

From the few links I followed after that, it indeed looks like a webkit2gtk bug, that only triggers in some particular scenario depending on how the DRM (Direct Rendering) functionality of the proprietary nvidia driver was configured (which is something that I struggled with a few months ago indeed, it's probably what put me in that scenario).

Thanks a lot @fnevgeny for your help troubleshooting this even though we knew pdfpc wasn't the culprit from the start!

TL;DR: set WEBKIT_DISABLE_DMABUF_RENDERER=1 as a topical workaround, or see elementary/browser#104 for potentially long term solutions while waiting for webkit to maybe fix the issue, but maybe try to understand what that link makes you do before actually doing it (messing with the driver configuration can be dangerous)

From "I can't see my notes" to "webkit is clashing with my GPU driver", computers are mean.

[fnevgeny]

However, I noticed every program that has had the issue so far print similar errors when they launch:

Yeah, I should've paid closer attention to your screenshots :).

TL;DR: set WEBKIT_DISABLE_DMABUF_RENDERER=1 as a topical workaround, or see elementary/browser#104

As noted there, it wouldn't work for < v2.41.1 (and indeed, it makes no difference under Ubuntu-22.04, for example).