Thanks Fox.
I’ve disabled the af_zz_imgproxy plugin, I’ll report back if it solves the issue.
I’ve seen the behaviour on both devices when they are on different connections. So I’m pretty sure that you are onto something with the proxy.
Disabling the zz-imgproxy plugin didn’t solve the issue.
I’ll have to get into the logcat to see what is failing and why.
What really makes this frustrating, is that the behaviour is not consistent, so sometimes the image fails to load and sometimes it loads just fine.
I get the same issue and haven’t looked enough to find cause as well. It is a few different comic feeds that have just the image in the body and no other text.
Pixel2
jah
8
I’ve been seeing this for a few months. There are some feeds that always have to be reloaded - eg xkcd - and some that never have to be reloaded - eg smbc. It’s almost like something is timing out - by the time I get to x, it’s just done loading images. I can’t tell what is coincidence and what isn’t. But it’s also not a big deal, at least not for me.
imgx64
9
Now that other people mention it… It happens with me with XKCD, but I’ve been assuming it was my Internet connection or something. Nexus 5X here.
fox
10
seems to be happening with specific feeds
imgx64
11
More info: I use the “no images” headline mode. Clicking on an XKCD comic loads the image correctly. Swiping from another post doesn’t load it.
fox
12
do images load properly within headlines if you enable the option? its interesting whether the problem is specific to webview or app in general.
I don’t use the app, but for those of you having the issue who also proxy or cache the images on your TT-RSS install, I’d be curious to know if your server’s access log actually shows an attempt to download the image. It might help determine if it’s the app, server, or upstream server that’s the issue.
imgx64
14
@fox
Images work in the headlines view, so only the article content WebView is affected, and only when I swipe to it from another article.
@JustAMacUser
I don’t proxy the images, so I can’t check.
FWIW The image loads if you rotate the display from portrait to landscape.
Also seems to just be feeds modified by the af_comics plugin for me.
imgx64
16
Rotating the screen loads the image immediately, seemingly without a network request.
I even tried this: swipe to image that wouldn’t load -> disconnect WiFi and mobile data -> rotate screen. And the image still showed.
klatch
17
My experience is the same as @imgx64 for everything he has said.
It’s not a feed-issue:
I’ve been seeing this consistently for several months now, including (but not exclusive to) a feed that I publish on the same server, with comics pulled locally by the server through my own proxy software. If the issue occurs, it’s always with an image from the same sources (e.g. XKCD), and never with most other sources. Not all of the affected sources have it with every image, but if the issue occurs with an image, it can always be reproduced with the same image, even in two different feeds. (e.g. the original feed)
It’s not a server/networking issue:
Apache access logs show nothing out of the ordinary for the requests to the proxied image. It’s just a 200. Size is correct. When you flip the device orientation, there is no additional network request because the image is retrieved from the app’s cache. And that’s the only way the image will show itself: if directly shown from the app cache. If the image is retrieved from the app’s “browser” cache through a network request with an if-modified-since, the apache log will show a 304 as expected, but even then the issue repeats itself regardless of the image already being downloaded before.
If you got an image in a feed this happens to you with, you can reproduce the issue always by closing the app, flushing the entire app cache, and go view the same image on the same feed through the app.
I wasn’t annoyed enough by the issue to see if this is some Android 8 or WebView specific bug.
fox
18
is this only on 8.0? it would help if you could replicate this on AVD (needs android studio and stuff, a lot of bullshit to setup) but then again i’m not sure what i could even do about it, webview is largely doing its own thing anyway.
i’m at a loss here, guys. 
If this is what I’ve also been seeing then it was happening on LineageOS 7.1-based Android as well. Definitely also happening on my new phone running 8.1.0.
My direct experience is that headlines view with image preview shows the image, but when I tap to look at just that single item often the image doesn’t show. I’d not yet tried rotating to see if it made any difference (does that still in effect get the app to restart at the new resolution ?).
It’s also on 7.1.1 on my Samsung tablet. I posted earlier.
From the other postings here I think it’s 100% related to Web view and I’m not sure that it’s something that you can fix Fox.
Perhaps a rollback of webview can be tried if that resolves the issue.
imgx64
21
You got it. Uninstalling Chrome (i.e. downgrading it to version 61) fixed the issue for me. Re-updating it back to 66 broke it again.
fox
22
i for one am glad that webview is a constantly broken perma-updating thing you can’t even test against
thanks, google
FWIW, the other day I tested a theory on my tablet.
I found a feed that had the issue, got the blank entry, put the tablet into flight mode, then rotated the screen and the image loaded instantly.
So from where I’m sitting the culprit is webview as the image is downloaded, which would explain why no errors are shown in TT-RSS.
I think we can close this issue as an “oh well, fuck it”
fox
24
its possible that the image is loaded but webview somehow glitches within tt-rss view hierarchy (which is rather complex for this view because android is a pile of garbage)[1]
it’s not like i can do anything about it though in this case, especially since it worked before. maybe google should learn to unfuck their own shit for once.
- you likely have no idea the sheer depths of shit i had to dive through to implement fullscreen video viewing for tt-rss, something that should in my personal opinion just work
