Description of problem: If I try viewing the source of the messages, many of them show blank screen. Strangely, some messages show the source, as expected. I'm seeing this with both imap+ and ews back ends. Occasionally, a message "Error opening file /: Is a directory" is displayed in the window, instead of the message source. Version-Release number of selected component (if applicable): evolution-3.26.6-1.fc27.x86_64 How reproducible: Most times. Steps to Reproduce: 1. Press Ctrl+U on a message. 2. Blank window opens. Actual results: Source not shown. Expected results: Source should show consistently. Additional info: On some messages, the source is displayed properly.
Thanks for a bug report. I realized I can reproduce it too, with a message downloaded under On This Computer. The other thing I realized is that when I downgrade webkitgtk4 packages from 2.20.0 to 2.18.6, then the message source can be viewed with no issue. There is no runtime warning shown on the console of evolution and the backtraces show both processes idle. I didn't do any further investigation to find the root cause, but the fact that the only change I made was to downgrade webkitgtk4 packages (and when I update only these back to 2.20.0 it breaks again), then I'm moving this to webkitgtk4 and I'll also add karma -1 to that update: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c923533479
Is there some crash? I would expect some.. It could maybe be https://retrace.fedoraproject.org/faf/reports/2077056/ that I'm looking into..
Also can you check whether there are some warnings in the Web Inspector (like preventing the load for some security reasons,..) after "loading" the message (that results in blank page)?
No, no crash involved here: [zyx@localhost ~]$ ps ax | grep WebKit 2077 pts/0 S+ 0:00 grep --color=auto WebKit [zyx@localhost ~]$ evolution& [1] 2084 [zyx@localhost ~]$ ps ax | grep WebKit 2117 pts/0 SLl 0:00 /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 1 44 2120 pts/0 SLl 0:00 /usr/libexec/webkit2gtk-4.0/WebKitNetworkProcess 2 44 2211 pts/0 S+ 0:00 grep --color=auto WebKit < Here I pressed Ctrl+U on the selected message, which had been shown in the message preview below the message list as well, and it opened a blank window. The message preview below message list didn't change, it didn't claim the webkit web process crashed or anything like that. > [zyx@localhost ~]$ ps ax | grep WebKit 2117 pts/0 SLl 0:00 /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 1 44 2120 pts/0 SLl 0:00 /usr/libexec/webkit2gtk-4.0/WebKitNetworkProcess 2 44 2220 pts/0 S+ 0:00 grep --color=auto WebKit [zyx@localhost ~]$ ps ax | grep WebKit 2235 pts/0 S+ 0:00 grep --color=auto WebKit [1]+ Done evolution [zyx@localhost ~]$
(In reply to Tomas Popela from comment #3) > Also can you check whether there are some warnings in the Web Inspector > (like preventing the load for some security reasons,..) after "loading" the > message (that results in blank page)? I'm not sure in which tab I should look, but in the Debugger tab, there's preselected "Sources->about:blank" and on the right there's written in huge red font "An error occurred trying to load the resource.", but nothing more, only this text.
(In reply to Milan Crha from comment #5) > I'm not sure in which tab I should look, but in the Debugger tab, there's > preselected "Sources->about:blank" and on the right there's written in huge > red font "An error occurred trying to load the resource.", but nothing more, > only this text. Usually it will be in the Web Inspector's Console tab.. Can you please check whether Evolution isn't blocking the load in its web extension (I think that it's in the “send-request” signal callback)?
(In reply to Milan Crha from comment #1) > Thanks for a bug report. I realized I can reproduce it too, with a message > downloaded under On This Computer. Just a note.. Trying this on F28 (WebKitGTK+ 2.20 and Evo 3.28) I can view the messages in On This Computer/Inbox without any problem.
(In reply to Tomas Popela from comment #6) > Usually it will be in the Web Inspector's Console tab.. Can you please check > whether Evolution isn't blocking the load in its web extension (I think that > it's in the “send-request” signal callback)? I see the same in the MiniBrowser when I type "about:blank" into the address bar, the same huge red text as mentioned in comment #5. Console shows nothing useful, from my point of view. Note running `MiniBrowser "about:blank"` doesn't work, in mangles that request to "about:///blank" in the address bar, thus I re-typed it inside the MiniBrowser again. (In reply to Tomas Popela from comment #7) > Just a note.. Trying this on F28 (WebKitGTK+ 2.20 and Evo 3.28) I can view > the messages in On This Computer/Inbox without any problem. Note it's the message source, not message itself (that works fine here). Trying on rawhide with webkit2gtk3-2.20.0-2.fc29.x86_64 and evolution-3.28.0-1.fc29.x86_64 gives me the same results, message source window is empty. My humble guess is that there's broken processing of "about:blank" page on the WebKit side.
> (In reply to Tomas Popela from comment #7) > > Just a note.. Trying this on F28 (WebKitGTK+ 2.20 and Evo 3.28) I can view > > the messages in On This Computer/Inbox without any problem. > > Note it's the message source, not message itself (that works fine here). Ah ok, sorry I misunderstood it. > My humble guess is that there's broken processing of "about:blank" page on > the WebKit side. I think that WebKit is preventing the load of the source and giving you only the blank page.
(In reply to Tomas Popela from comment #9) > Ah ok, sorry I misunderstood it. No problem. Does it mean that you can reproduce on F28 too? I'd like to confirm it for a sake of completeness. > I think that WebKit is preventing the load of the source and giving you only > the blank page. Except "about:blank" is a "page" which should be always accessible. :) Funnily enough, it did provide the blank page, but then didn't move further for some reason.
(In reply to Milan Crha from comment #10) > No problem. Does it mean that you can reproduce on F28 too? Yes. > Except "about:blank" is a "page" which should be always accessible. :) > Funnily enough, it did provide the blank page, but then didn't move further > for some reason. I don't know what you mean by that. What I was saying that when WebKit fails to load something because of some policy then it will automatically load the blank page.
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=794694
WebKit doesn't know anything about about:blank, that's an Epiphany feature. See ephy_about_handler_handle_blank() in ephy-about-handler.c where it loads "<html></html>".
(In reply to Michael Catanzaro from comment #13) > WebKit doesn't know anything about about:blank, that's an Epiphany feature. > See ephy_about_handler_handle_blank() in ephy-about-handler.c where it loads > "<html></html>". Do you mean that since 2.20.0 of webkitgtk4 every single user of it whom wants to access about:blank is supposed to provide its own handler for it? That's an API change (yeah, I call it API change, because it's the closest term from my point of view), thus as such it cannot go to other than rawhide (and Fedora 28), right?
I don't know that we've intentionally changed anything here, but about:blank is not a URI so I'd be really surprised if that ever loaded anything....
(In reply to Milan Crha from comment #14) > That's an API change (yeah, I call it API change, because it's the closest > term from my point of view), thus as such it cannot go to other than rawhide > (and Fedora 28), right? Milan, please STOP. We had this discussion several times. I told you that you to take the WebKitGTK+ as security sensitive component as other browsers like Firefox or Chrom[e|ium]. There are users that use it as a daily browser to access their online banking and do other security sensitive activities. And WebKitGTK+ follows the same policy as them - we are rebasing to the latest stable release in every supported Fedora at the time to bring the security fixes to all of our users. Also there is a risk that something could break, but that's happening also for Firefox or Chrom[e|ium] users. But we will try our best to resolve the issue, but the WebKitGTK+ 2.2x will go to F26+ - there is no discussion about that.
(In reply to Tomas Popela from comment #16) > Milan, please STOP... Oh, I'm not questioning the intention, it does make perfect sense. The only problem is that the user base for the development version is significantly lower than the user base of the stable version. Thus it can easily happen, like it did now, that some changed behaviour is found only after the version is used by those folks on the stable versions. And that's all. It's expected you'll fix the regressions in webkit, not in applications, at least in the non-rawhide versions of Fedora. I've really nothing against it.
One observation: Using an IMAP (or any remote) account and a message which is not downloaded yet (the Mail view has disabled Preview panel, thus by selecting the message it's not downloaded), then the message source window shows: Retrieving message XXX for a bit of time, then the window content is replaced with the message content. When the selected message is already downloaded in the local cache, then the window opens empty. I guess the difference is the delay when the message is downloaded over the network. WebKit has enough time to show the "Retrieving message XXX" page when the message is not in the local cache, while when the message is already downloaded the message content is requested to be loaded in the webkit quickly after the "Retrieving message XXX" page is requested, possibly before its load is finished. I've no proof for this, though, it's only a conclusion I'd do after the observation of the consequences.
Did this ever get reported upstream? Do we have any idea what's going wrong inside WebKit?
(In reply to Michael Catanzaro from comment #19) > Did this ever get reported upstream? It "is" - https://bugs.webkit.org/show_bug.cgi?id=153210. When I tried the debug build with patch from the bug applied then I the source was shown (before I hit another assertion). I tried the release build, but it didn't helped there.
It also shows "Error opening file /: Is a directory" instead of the message source here sometimes if the mail had previously downloaded images. But most of the time, it is just a blank white screen.
With Tomas' help, whom pinpointed the issue, I made a change in evolution to prevent this state. It can happen that the EMailDisplay's reload, due to property changes, is scheduled for idle during the EMailBrowser construction and that idle callback is called when WebKitGTK+ doesn't have loaded expected URI in it, only "about:blank". Calling reload in such state can prevent the real (and possibly ongoing) request to be cancelled, which results in an empty message preview. Avoiding schedule of such false reload helps to prevent this situation. While this is sort of fine with Fedora 28, I'm unsure what to do in older Fedoras. I do not want to do another release of the old Evolution for sure. Maybe have it fixed in F28+ only. Created commit c903384a2c in evo master (3.29.1+) [1] Created commit a87218979f in evo gnome-3-28 (3.28.2+) [1] https://git.gnome.org/browse/evolution/commit/?id=c903384a2c
Then would need to be fixed in WK 2.20 presumably, since F27 has another ~ 8 months of support left, and WK 2.20 is considered a security release?
There seems to be a bit of a pattern to the behaviour here (tested with evolution-3.26.6-1.fc27.x86_64 and webkitgtk4-2.20.1-1.fc27.x86_64). If an email has an attachment (as shown by the paperclip sign that does not disappear when the email is clicked), the source can usually be viewed. For other emails, blank page.
*** Bug 1578508 has been marked as a duplicate of this bug. ***