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.

13

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.

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.

15

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.

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.

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.

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. :man_shrugging:

19

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 ?).

20

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.

21

:tada:

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.

22

i for one am glad that webview is a constantly broken perma-updating thing you can’t even test against

thanks, google

23

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”

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.

  1. 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
25

I am also experiencing this bug on android 7.1.1 (Xperia Z5 Compact) with Chrome 66.0.3359.126 for a few months. As a consequence I don’t use this app anymore despite the fact that I paid for it.

26

the suffering i have to go through because of you guys. the pain. the depths of desolation and sorrow.

i’m still investigating but it looks like rendering webview content synchronously fixes this issue (at least xkcd starts to render properly).

best part is how it’s impossible to test or replicate this on a virtual device because it obviously uses a completely different(ly broken) webview implementation and you can’t install chrome-based webview because fuck you, lol.

e: i’m updating current rollout with the version that fixes this (maybe) - 1.242

e2: and this is the thanks i get:

05ZhxVeF

lmao

27

Latest beta fixed XKCD for me.

28

Fixed now with latest beta (1.242(476))
Tested on xkcd and Dilbert

29

This fixes it for me. I had it with rss-bridge instagram feeds. Thanks.

30

Last update fixed the issue for me as well :smiley:

@fox you are so right libraries like webview should reduce complexity and not add… :roll_eyes:

31

Just out of curiosity, was this related to this bug ? Google Fixes Issue That Broke Millions of Web-Based Games in Chrome