Bug 401176 - No embedded videos in software description, just blank space and nonclickable links
Summary: No embedded videos in software description, just blank space and nonclickable...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-knewstuff
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.54.0
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Jeremy Whiting
URL: kns://kwineffect.knsrc/api.kde-look.o...
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-18 19:24 UTC by Adam Golański
Modified: 2019-04-30 18:46 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.15.0
Sentry Crash Report:


Attachments
Discover app with blank popup (79.67 KB, image/png)
2018-11-18 19:24 UTC, Adam Golański
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Golański 2018-11-18 19:24:14 UTC
Created attachment 116391 [details]
Discover app with blank popup

SUMMARY


STEPS TO REPRODUCE
1. Open Discovery
2. Find "Cool Effect" (https://store.kde.org/p/1110512)


OBSERVED RESULT

Under Watch this video is blank space and non-clickable, non-selectable link. User can click this blank space to open empty preview pop-up box.


EXPECTED RESULT

embedded player and/or clickable/selectable link.
Actually in given example this video is non-existent on YouTube, but still, even without player, link should be at least selectable, to enable copying it to clipboard. 


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.14.3
KDE Frameworks Version: 5.52.0
Qt Version: 5.11.2
Comment 1 Dan Leinir Turthra Jensen 2018-11-19 13:11:28 UTC
Absolutely agreed, it would be more than a bit handy to have the youtube link (and indeed any clear-text links in the description) clickable, perhaps even with a useful context menu to let people either open the link or copy it... Whether or not the youtube link is, in fact, a functioning video is less important, the fact that it is there at all as a URL ought to yield something clickable, or at least copyable. Current state does seem less than amazingly useful. Thank you for pointing it out :)
Comment 2 Nate Graham 2018-11-20 14:48:08 UTC
Fixed with https://phabricator.kde.org/D17050.

Not sure why the bug didn't get updated automatically.
Comment 3 Dan Leinir Turthra Jensen 2018-11-21 11:19:42 UTC
(In reply to Nate Graham from comment #2)
> Fixed with https://phabricator.kde.org/D17050.
> 
> Not sure why the bug didn't get updated automatically.

This is a Very Annoying Problem, and apparently the sysadmins have no idea why it happens - at least the couple of times it's been brought up they've kind of shrugged (which, i'm fine, i know they're snowed under). My account, specifically, is not being mapped between commits and bug reports, and consequently the bugs.kde.org entries don't get updated. It works fine for the Phabricator keywords, so i can only imagine something's wonky with the hook for bko, but yeah, no idea apart from that :P
Comment 4 Patrick Silva 2019-01-22 16:45:35 UTC
This bug persists in discover 5.15 beta.
Can we reopen it?
Comment 5 Nate Graham 2019-01-22 23:46:57 UTC
Well, it's half-fixed.

The link is indeed clickable now. However the link doesn't actually point to a valid video. So there's a big clickable empty area in Discover that loads... nothing. That part isn't fixed yet.

On the webpage (https://store.kde.org/p/1110512) there's also no image or thumbnail there because the youtube video link isn't valid, but the emptiness doesn't take up so much space. Could be that the KNS backend isn't properly signaling that there's no content here so Discover reserves space for something empty. Just guessing.

Dan, any thoughts?
Comment 6 Dan Leinir Turthra Jensen 2019-01-23 11:42:02 UTC
The very large empty area is the screenshots section, which because there are no screenshots is not showing anything useful... i'll try and see what's going on there, and why we're still seeing that, even if all the screenshot options are empty. But yes, basically confirmed that it is there. (the issue has nothing at all to do with the video, rather that there's just no usable screenshots for this ocs entry, which isn't being catered for somewhere...)
Comment 7 Dan Leinir Turthra Jensen 2019-01-23 13:11:25 UTC
Hm, right, so the problem that's being seen here is that when an item on opendesktop.org doesn't have any screenshots, a default one will be assigned to the first item. As such, we get returned this link[1] as the first (and only) screenshot. In other words: Discover is doing what it's supposed to. I feel like it would probably not be entirely reasonable to handle this in the client, but rather we need the store to return something more usable through the api...

[1] https://cn.opendesktop.org/cache/100x100-0/img/default.png
Comment 8 Nate Graham 2019-01-23 22:51:22 UTC
Yikes, nice find! That seems like a subpar behavior that messes up clients like Discover, which is otherwise capable of displaying an adequate page with no screenshots.

Should we move this bug to attica or kns?
Comment 9 Dan Leinir Turthra Jensen 2019-01-24 09:42:05 UTC
i have notified the store people about the issue, but yes, it's not Discover's fault... KNS would seem a sensible place for handling this issue on the client. Attica is a pure consumption library, it doesn't have any heuristics logic type stuff in it, where KNewStuff does in places, so... yeah, reassigning to KNewStuff seems to make sense.
Comment 10 Nate Graham 2019-01-24 18:30:09 UTC
Awesome, thanks Dan!
Comment 11 Dan Leinir Turthra Jensen 2019-04-29 11:05:44 UTC
i'm happy to announce that the transparent default screenshot is now a thing of the past and that the GHNS dialogues and Discover both look much nicer now :) I am unsure of whether we do want to do some heurustic work in KNewStuff here, though...
Comment 12 Nate Graham 2019-04-30 18:46:34 UTC
So much nicer! I think it's good enough now.