Screen Is Completely White

[username227]

Hi,

this just started. It appears to be a visual problem. When I start the program, the program starts and it appears to load my transmission properly. However, the screen remains completely white. Only the name of my server is on top (see attached visual).

Now, if I double-click on the screen, it will still open the torrent location, which I find quite interesting. However, I can't see anything except white. It was working earlier today, so perhaps something update upstream from the arch repositories affected it? If you have any ideas on what package it might have been, I can try downgrading to determine the issue.

[username227]

UPDATE: Using the dependencies list on the precompiled deb file, I have tracked the source of the problem to the latest upgrade of webkit2gtk. The latest version, 2.42.0-1, causes the screen to be completely white. The older version, 2.40.5-2, works fine.

For now, I have instructed pacman to ignore this upgrade. Hope this helps with a longer-term solution.

[qu1ck]

White screen is usually javascript errors but in that case I wouldn't expect double clicking invisible torrents to work.

Can you check if there are any errors in browser console? To open the console right click somewhere where torrent details panel is and choose "inspect".

[username227]

OK so I assume you mean with the old version of webkit2gtk, since with the new version I can't see anything. I think I did this correctly, can't swear to it. this is what I found:

console.txt

[qu1ck]

No, I meant with the new webkit2gtk. The right click menu should still show up if you click around a bit. The log you attached works, I just need it from the non-working case.

[username227]

No, I meant with the new webkit2gtk. The right click menu should still show up if you click around a bit. The log you attached works, I just need it from the non-working case.

OK I was able to see and click on Inspect Element. However, the console itself is whited out just like the rest of the program and I can't see anything to copy it. Sorry.

[qu1ck]

the console itself is whited out

That's definitely a webkit glitch then and not caused by the app. If you can, report it to maintainers of the package.

[username227]

the console itself is whited out

That's definitely a webkit glitch then and not caused by the app. If you can, report it to maintainers of the package.

OK. I put the report in here: https://bugs.webkit.org/show_bug.cgi?id=261874. Hopefully this is the right place.

[qu1ck]

Thanks, judging by the discussion on that bug the issue is confirmed on webkitgtk and/or nvidia driver side.

[username227]

OK so you pushed it off to webkit (and I believe you were correct for doing so). Webkit is pushing it off to Nvidia (which I believe is incorrect) and the problem won't get solved. Is there no other way to get the program to render with nvidia that will get around the problem? (I hate when this happens; extremely frustrating).

For context, they claim that they changed the rendering code around in the new version which is why it works with the old version; they also simultaneously claim that it's a nvidia bug. I don't believe both of these can be true.....

[qu1ck]

No, sorry, that is entirely out of control of the app.

Webkit are probably right saying that the problem is with Nvidia but it's kind of like arguing with a truck about right of way when you are on a bicycle. Would you rather be right or not become a hood ornament? The reality of the linux video drivers is that software has to work around driver bugs, it's not windows were it's often the other way around.

Only thing I can suggest you do is try to reinstall the nvidia driver if you use proprietary one. It's been a while since I did that but I remember their installer compiling some modules on the fly. If you upgraded kernel or other core libs since you have installed the driver you may have to recompile them so a reinstall may fix something. But this is honestly a hail mary.

[username227]

good idea but didn't work. thanks. I'm not a big flatpak fan because of the size of the programs, but if you were to get this program into a flatpak that would likely solve the issue for me since they come with their own dependencies.

[qu1ck]

Being in a flatpak quarantine will break path mapping functionality. Without it you might as well just use the web ui version of TrguiNG.

Random question, you did compile TrguiNG yourself, right? And you recompiled it when upgrading webkitgtk?

[username227]

Yes, I did that. I thought I had done something myself to the settings; I recompiled, searched and changed the config file to start from scratch, etc. but it didn't work.

AHA, interesting about the flatpak. Yeah, the mapping is very important for me. This program is already far superior to transgui, and I'd rather not go back. In the short term, i'll stick with the downgraded version of webkit and hope that something gets fixed down the line. Once that ends up breaking something else, I guess i'll have to switch to hybrid mode.

[qu1ck]

Yeah, that's probably your best bet.

I'm glad you are liking the program :)

[username227]

Yeah, that's probably your best bet.

I'm glad you are liking the program :)

Thank you for your work on this and also for being willing to answer so quickly.

[username227]

OK there's a workaround for this bug that the kind folks at webkit showed me. I'll post it here in case anybody else uses nvidia and has an issue:

If you run the program with a changed environment variable, the program will work fine. This is more like a workaround than a solution until their code changes in the newest version can be made to work with nvidia.

I just created a trguing.sh script with the following:

!

export WEBKIT_DISABLE_DMABUF_RENDERER=1 && /home/jerry/TrguiNG/src-tauri/target/release/trgui-ng

I pointed my desktop environment to this shell script and now it works fine.

This workaround is far better than maintaining an outdated package until webkit figures things out.

[username227]

Seems like someone at webkit may have finally tracked the problem. their bug report linked to this:

https://internals.rust-lang.org/t/global-symbols-from-statically-linked-system-libraries/19954

some sort of quirk in rust, but it may as well have been greek to me. You might find it interesting, though.

As a side note, you may want to update the readme to indicate that a segfault on nvidia instead of a white screen could also be result of the same bug, with the same environment variable solution.

[mcatanzaro]

Seems like someone at webkit may have finally tracked the problem.

That was an NVIDIA engineer going above and beyond.

I have no clue how to deal with this problem but it's not something that WebKit or NVIDIA can help with. Probably TrguiNG will need to somehow stop static linking to libdbus, although that might be easier said than done. Good luck.

[username227]

Seems like someone at webkit may have finally tracked the problem.

That was an NVIDIA engineer going above and beyond.

I have no clue how to deal with this problem but it's not something that WebKit or NVIDIA can help with. Probably TrguiNG will need to somehow stop static linking to libdbus, although that might be easier said than done. Good luck.

Yes, they closed the issue and said it's on rust and the app developers. :-(

[mcatanzaro]

Maybe you could build libdbus within a separate namespace somehow. There's probably some way? No clue; linkers are confusing.

[qu1ck]

Yeah I was following the bug and saw the link. Great analysis and a really hairy problem too. Luckily it may be as simple as disabling static linking for dbus, it is actually supported by dbus rust bindings but the lib I'm using that depends on it doesn't do that. https://github.com/Seeker14491/opener/issues/27#issuecomment-1961841923