On current Fedora Rawhide, with evolution-3.48.1-1.fc39.x86_64 and webkit2gtk4.1-2.41.3-1.fc39.x86_64 , the content of the preview pane often suddenly disappears. It still reacts as if it's there - if you blindly click on a link it will open - but you can't see it. Clicking anywhere in the preview pane after this happens brings it back, so it's not fatal, just annoying. There doesn't seem to be an obvious specific trigger for the bug, it just...happens, quite often (like, every few minutes I'll look at the Evo window and it'll be blank). It's happened twice while I've been writing this bug report. Reproducible: Sometimes Steps to Reproduce: 1. Run Evolution, use normally 2. Observe the preview pane as you use the system normally Actual Results: Preview pane often suddenly goes blank Expected Results: Preview pane should keep showing contents
Thanks for a bug report. I cannot reproduce it reliably, it happened once out of 50+ tries. The preview panel was all "grey", no headers, no content shown, but moving mouse above the preview panel did react to links and such, which should be there, only not visible. Even the scrollbar showed up after I moved the mouse cursor above it. I guess there's missing "redraw" signal, but whether it's a thing in gtk3 or WebKitGTK I do not know. It's WebKitGTK responsible for the content of the preview panel for sure, thus let's move this there for further investigation. This is with gtk3-3.24.37-1.fc39.x86_64 and the same evolution and WebKitGTK versions as you have.
Does it happen when running with WEBKIT_DISABLE_DMABUF_RENDERER=1? Milan, is it creating new web views or is it reusing an existing view? If it happens right after creating a new web view, then it's https://bugs.webkit.org/show_bug.cgi?id=254919
Huh, weird that it happens more for me than you, Milan. Though it's not consistently frequent for me either...right now it hasn't happened since I started using the system this morning (about 15 minutes ago). There probably is *some* kind of triggering behavior, it's just not obvious to me what it is. FWIW I run Evo on the left-hand half of my main monitor, a 4K display, at 125% fractional scaling, with Firefox on the right half. Sharing the left half with Evo are gedit and a second Firefox window; there's a terminal floating over there too. I don't think it's what mcatanzaro thinks, probably, because sometimes it happens when nothing is really 'going on' in Evolution. Like, I'm just over here typing in Firefox and suddenly the preview pane goes grey. I don't see why it would suddenly have created a new web view without me switching to a different message or something?
Huh, after a reboot it suddenly went into a weird state (not immediately on reboot, shortly after I logged in). The preview pane was flickering constantly. I tried to get a video of it, but opening the screenshot control pane made it go completely black. After *closing* the screenshot pane, bits of it are left behind in the Evo preview pane, still flickering constantly. Here's a phone video: https://fedorapeople.org/groups/qa/2192408-evo-bug.mp4 . Not sure if the flickering comes through.
(In reply to Michael Catanzaro from comment #2) > Does it happen when running with WEBKIT_DISABLE_DMABUF_RENDERER=1? > > Milan, is it creating new web views or is it reusing an existing view? If it > happens right after creating a new web view, then it's > https://bugs.webkit.org/show_bug.cgi?id=254919 So I've been running it this way for three hours and it *just* happened a few times now, I thought that had fixed it for a while.
> is it creating new web views or is it reusing an existing view? There is a single WebKitWebView in the window, as the preview panel, and it is filled with the selected message. No delete & create a new one instance involved here, on a message selection change.
Just noticed today, this also affects the message composer.
I though it's broken since the message is selected, but it's not the case. These steps seem to reproduce this most often for me: a) select a different message to be viewed - it's shown in the preview panel below the message list b) right-click the selected folder in the folder tree on the left and pick Properties c) click three times on a checkbox "Copy for offline use" (I have the folder set to do the copy) d) click the Close button - the mouse cursor is now roughly in the middle of the preview panel, which still shows the message content e) move mouse cursor away from the web view - I usually move it to the top, but to the left worked as well As soon as the mouse moves away from the web view the web view turns into grey. Te items inside are still there, I can move the cursor abot the scrollbar and it suddenly appears. If the page has any buttons (like when there's an attachent), the buttons are shown too after moveing above them. This does not apply to the links. When I click to the message body, like if I'd like to focus the web view, the whole page redraws and everything is fine again. All the steps are needed here, skipping any of them does not reproduce the problem. Even the a), selecting a new message to be viewed, is required. It happens also when I run Evolution as: WEBKIT_DISABLE_DMABUF_RENDERER=1 evolution I run the rawhide in a virtual machine. There is this printed after the evolution start: libEGL warning: pci id for fd 16: 1b36:0100, driver (null) I do not know whether it's related. I saw different libEGL notices in the virtual machines, but none have any visible impact. This warning is shown shortly after start, before the bug exhibits.
I'm not doing anything like your steps to trigger it, FWIW. My use of Evolution is quite 'simple' - I browse folders, click on emails, create new ones, reply to existing ones, and occasionally forward them. That's more or less it. I rarely right-click the folder tree (definitely am not doing that to trigger this). I've never used "Copy for offline use". The only thing I do semi-regularly which creates additional windows is compose an email, but I don't think I'm even doing that each time this bug happens.
I use it more or less the same. The steps I gave help me to reproduce the problem reliably. Why it's these steps I do not know. I did see it without them too, but only occasionally, quite rarely, definitely not reliably.
I think we need an upstream bug report (WebKit Bugzilla) to make further progress on this one.
Here you are: https://bugs.webkit.org/show_bug.cgi?id=257368
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
Closing since this was reported upstream.