Bug 436049

Summary: Epiphany Browser Webapps fail to launch due to lack of execute permissions on .desktop files
Product: [Frameworks and Libraries] frameworks-kio Reporter: angeltmail
Component: generalAssignee: KIO Bugs <kio-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: a.samirh78, alexander.lohnau, kdelibs-bugs-null, nate
Priority: NOR    
Version First Reported In: 5.81.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: https://invent.kde.org/frameworks/kio/commit/9fef54905d25fcebe7f3f554537df4ceef49a541 Version Fixed/Implemented In:
Sentry Crash Report:

Description angeltmail 2021-04-22 16:26:19 UTC 
SUMMARY

Installing applications through epiphany browser and running them from krunner or Application Dashboard leads to a failed launch due to being "not authorized to execute this file."

STEPS TO REPRODUCE
1. Open Epiphany Browser
2. Navigate to website
3. Open Hamburger Menu/Popover Menu at the top right.
4. Click "Install Site as Web Application..."
5. Run the new application through krunner or Application Dashboard.

OBSERVED RESULT

Receive error notification stating: "Launching DuckDuckGo (Failed) | You are not authorized to execute this file." (replace DuckDuckGo with the name of the site used.)


EXPECTED RESULT

Webapp to launch through epiphany browser.


SOFTWARE/OS VERSIONS

Distro: Arch Linux 
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2

Epiphany Browser Version: 40.0
 

ADDITIONAL INFORMATION

I do not know under what program this would be classified as, so I am posting it here.

running `sudo chmod +x ~/.local/share/applications/org.gnome.Epiphany.WebApp-duckduckgo-96626ae2c8748ce47d19e235e6dcc811d4279748.desktop` makes the application start properly from krunner or Application Dashboard.

Initially I reported this bug to epiphany browser's git issues and was suggested to report it to the kde devs. Here is the link to the issue: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1511
Comment 1 Alexander Lohnau 2021-04-23 13:24:38 UTC 
It seems that it is caused by the desktop files being symlinks and in KIO no untrustedProgramHandler is found in KIO::ApplicationLauncherJob::start
Comment 2 Bug Janitor Service 2021-04-24 10:50:54 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/427
Comment 3 David Faure 2021-05-13 23:06:50 UTC 
Git commit 9fef54905d25fcebe7f3f554537df4ceef49a541 by David Faure, on behalf of Ahmad Samir.
Committed on 13/05/2021 at 23:06.
Pushed by dfaure into branch 'master'.

When finding a job delegate extension, also try the uiDelegate() of its parents

A use case for this is an OpenUrlJob, urlJob, that has a KIO::JobUiDelegate,
it tries to open a .desktop file, and ends up creating an
ApplicationLauncherJob subjob, appJob:
- calling appJob->setUiDelegate(urlJob->uiDelegate()) won't work because
  the uiDelegate() of urlJob is already tracking a job
- creating a new, basic, KJobUiDelegate for appJob won't work because we need
  a KIO::JobUiDelegate (e.g. to get a untrustedProgramInterface if the .desktop
  file isn't owned by root and isn't executable), however KIO::JobUiDelegate
  is in KIOWidgets and those jobs are in KIOGui

Instead, change KIO::delegateExtension() to check the uiDelegate() of the
parent of its KJob arg, if that parent is a KCompositeJob (the only class
that can have sub-jobs).
And if that doesn't work, check the parent of the parent... etc (dfaure's
suggestion); until we find one or return nulltpr.

M  +14   -1    src/core/jobuidelegatefactory.h

https://invent.kde.org/frameworks/kio/commit/9fef54905d25fcebe7f3f554537df4ceef49a541