Description of problem: Whenever Epiphany crashes, it appears in gnome-abrt as "BBC iPlayer" which is pretty insane. It seems to be one of the default desktop files installed by Epiphany (into ~/.local/share/applications) that launches the normal Epiphany binary in application mode: Note that I've never used this web app (it even has NoDisplay=true), so it's really confusing. [Desktop Entry] Name=BBC iPlayer Comment=Catch up on BBC TV and Radio programmes, or watch/listen live Exec=epiphany --application-mode --profile="/home/mcatanzaro/.config/epiphany/app-epiphany-bbciplayer-23ce23f45976e71a9dbbd3e728ade6acf6f2067d" http://www.bbc.co.uk/iplayer/bigscreen StartupNotify=true Terminal=false NoDisplay=true Type=Application Icon=/home/mcatanzaro/.config/epiphany/app-epiphany-bbciplayer-23ce23f45976e71a9dbbd3e728ade6acf6f2067d/app-icon.png StartupWMClass=epiphany-bbciplayer-23ce23f45976e71a9dbbd3e728ade6acf6f2067d Version-Release number of selected component: gnome-abrt-0.3.7 Additional info: reporter: libreport-2.2.2 kernel: 3.15.4-200.fc20.x86_64 type: libreport
Created attachment 918854 [details] Screenshot of issue
Hello, I installed Epiphany and my ~/.local/share/applications was empty. So, I opened http://www.bbc.co.uk/iplayer/bigscreen, clicked the gear -> "Save As Web Application" and it created a desktop entry like yours. Unfortunately, my desktop entry for BBC does not have 'NoDisplay=true', so I have to find a different way how to identify these desktop entries. Perhaps I can try to limit searched desktop files to system only, but GIO do not offer such an option. If I run epiphany ("Web" application) and kill it with SEGV, ABRT GUI displays "Web" in the problems list. If I run BBC application ("BBC iPlayer" application) and kill it with SEGV, ABRT GUI displays "BBC iPlayer" in the problems list. I am not an UX expert so I need your help. What do you think about it, what would be the best for users? (they see "BBC iPlayer" in Task bar, they clicked "BBC iPlayer" in Applications) I can filter out "NoDisplay=true" desktop items, but what else should I filter out?
(In reply to Jakub Filak from comment #2) > Hello, I installed Epiphany and my ~/.local/share/applications was empty. > So, I opened http://www.bbc.co.uk/iplayer/bigscreen, clicked the gear -> > "Save As Web Application" and it created a desktop entry like yours. > Unfortunately, my desktop entry for BBC does not have 'NoDisplay=true', so I > have to find a different way how to identify these desktop entries. Normal web apps would not have NoDisplay set. I'm frankly not sure why Epiphany created these for me. Filtering apps with NoDisplay might be a good place to start, though, but I'm not sure it's really necessary. > Perhaps > I can try to limit searched desktop files to system only, but GIO do not > offer such an option. Hm... would that conflict with ABRT's hidden feature for processing unpackaged files? > If I run epiphany ("Web" application) and kill it with SEGV, ABRT GUI > displays "Web" in the problems list. If I run BBC application ("BBC iPlayer" > application) and kill it with SEGV, ABRT GUI displays "BBC iPlayer" in the > problems list. I am not an UX expert so I need your help. What do you think > about it, what would be the best for users? (they see "BBC iPlayer" in Task > bar, they clicked "BBC iPlayer" in Applications) Hm, I think it would be better to always show Epiphany rather than the web app name, since Epiphany and not the web app is not responsible for the crash... but either way, this is not really a big deal. What's more important is that when Epiphany is not running as a web app, the crash should not be reported as if it was coming from a web app. Probably the thing to do here would be to be more strict with the Exec line when looking for a matching desktop file. I think you're currently discarding everything after the executable name in the desktop file when deciding which desktop file matches the crash, right? That's probably a good fallback, but I would first prefer a desktop file that best matches the actual command line of the crashing program. Specifically, I would expect a desktop file with Exec=epiphany to be matched rather than one with Exec=epiphany --whatever
(In reply to Michael Catanzaro from comment #3) > (In reply to Jakub Filak from comment #2) > > Hello, I installed Epiphany and my ~/.local/share/applications was empty. > > So, I opened http://www.bbc.co.uk/iplayer/bigscreen, clicked the gear -> > > "Save As Web Application" and it created a desktop entry like yours. > > Unfortunately, my desktop entry for BBC does not have 'NoDisplay=true', so I > > have to find a different way how to identify these desktop entries. > > Normal web apps would not have NoDisplay set. I'm frankly not sure why > Epiphany created these for me. Filtering apps with NoDisplay might be a good > place to start, though, but I'm not sure it's really necessary. > > > Perhaps > > I can try to limit searched desktop files to system only, but GIO do not > > offer such an option. > > Hm... would that conflict with ABRT's hidden feature for processing > unpackaged files? > No. The detection of unpackaged files has nothing common with displaying icons and human readable names in the GUI. ABRT uses 'rpm -qf $absolute_path_to_crashed_executable' to detect unpackaged executables. > > If I run epiphany ("Web" application) and kill it with SEGV, ABRT GUI > > displays "Web" in the problems list. If I run BBC application ("BBC iPlayer" > > application) and kill it with SEGV, ABRT GUI displays "BBC iPlayer" in the > > problems list. I am not an UX expert so I need your help. What do you think > > about it, what would be the best for users? (they see "BBC iPlayer" in Task > > bar, they clicked "BBC iPlayer" in Applications) > > What's more > important is that when Epiphany is not running as a web app, the crash > should not be reported as if it was coming from a web app. Sure, the crash is always reported as a bug in Epiphany. > > Probably the thing to do here would be to be more strict with the Exec line > when looking for a matching desktop file. I think you're currently > discarding everything after the executable name in the desktop file when > deciding which desktop file matches the crash, right? No. The executable comparison is the last possibility to find the corresponding desktop file [1]. > That's probably a good fallback, Sure. > but I would first prefer a desktop file that best matches the > actual command line of the crashing program. Me as well. > Specifically, I would expect a > desktop file with Exec=epiphany to be matched rather than one with > Exec=epiphany --whatever Yes, as I wrote in comment #2, it works on my F20 box. Could you please attach Epiphany's desktop file and 'cmdline', 'executable' and 'component' files from the dump directory? 1: https://github.com/abrt/gnome-abrt/blob/master/src/gnome_abrt/application.py#L119
Created attachment 919173 [details] cmdline
Created attachment 919174 [details] executable
Created attachment 919175 [details] component
Created attachment 919176 [details] epiphany.desktop Here's the real epiphany.desktop
Created attachment 919177 [details] bogus epiphany.desktop Here's the epiphany.desktop that abrt seems to be using.
(In reply to Jakub Filak from comment #4) > > What's more > > important is that when Epiphany is not running as a web app, the crash > > should not be reported as if it was coming from a web app. > > Sure, the crash is always reported as a bug in Epiphany. What I meant to say is, the crash should not be presented to the user as a bug in a web app if Epiphany is not running in web app mode. I don't care too much what happens if Epiphany is actually running as a web app, whether the crash is presented as an Epiphany crash or a crash of that particular web app (as long as ABRT does not present it as a different web app). Try installing that BBC desktop file in ~/.local/share/applications, then I think you'll be able to reproduce this if you send SIGSEGV to Epiphany (not running as a web app).
Thank you for the files Michael! I found a bug in usage of os.path.basename() but it is not the root cause of your issue. The root cause of your is that Epiphany's Exec key is "epiphany %U", therefore the GUI rejects its desktop file for all variants of command line ('epiphany', 'epiphany http://bugzilla.redhat.com/', etc.), because the GUI do not understand the Exec key format yet, and fallbacks to the search by executable where both Epiphany's file and the bogus file have the same value "epiphany". Unfortunately, the bogus file is accessed first.
Michael, could you please install the following scratch build, retest and report the results here? http://koji.fedoraproject.org/koji/taskinfo?taskID=7176548
Jakub, I think that build fixes it, thanks!
(In reply to Michael Catanzaro from comment #13) Thank you for your cooperation! Upstream commit https://github.com/abrt/gnome-abrt/commit/dfa92d13f6843f2fba71f81e7b001f008951b686 fixes this bug.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.