Hide Forgot
Description of problem: Values in the list of details associated with window "Problem description" appear to be editable but after overwriting an existing value and confirming the new one, the old value is restored. This behaviour is problematic from the privacy point of view because a bunch of personal data is reported e.g. in section "environ". Version-Release number of selected component (if applicable): abrt-2.0.2-5.fc15 How reproducible: Always. Steps to Reproduce: 1. Trigger a crash reported through abrt. 2. Try to edit values of details in the problem description. Actual results: Text fields appear to be editable but new values are not accepted. Expected results: Text fields are editable to respect user privacy. Additional info: Backtraces are editable exactly to preserve user privacy.
This may be addressing the same issue: Bug 711580 - privacy may be compromised by some environment variables in the report
*** Bug 711580 has been marked as a duplicate of this bug. ***
*** Bug 713553 has been marked as a duplicate of this bug. ***
*** Bug 655580 has been marked as a duplicate of this bug. ***
Fixed in git: commit 8e369296f77d5a9d3e4dd146a77bdcc9ec1e8186 Author: Denys Vlasenko <dvlasenk> Date: Sat Jul 16 11:16:02 2011 +0200 wizard: save edited lines if they are EDITABLE
abrt-2.0.7-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/abrt-2.0.7-2.fc16
Package abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.7-2.fc16 libreport-2.0.8-3.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16990/libreport-2.0.8-3.fc16,abrt-2.0.7-2.fc16 then log in and leave karma (feedback).
unfortunately, this doesn't seem to be fixed [kvolny@kvolny ~]$ rpm -q abrt-gui abrt-gui-2.0.7-2.fc16.x86_64 at the Problem description screen, if I try to edit for example the "cmdline", it seems that the value gets changed, but if I go next and then back, the original value gets restored; also at the Review the data scrreen the cmdline tab shows the original value instead of the one I've entered
This is fixed by libreport-2.0.8, are you sure you have it installed? I can change the cmdline and it's saved just fine.
(In reply to comment #9) > This is fixed by libreport-2.0.8, are you sure you have it installed? I can > change the cmdline and it's saved just fine. [root@kvolny ~]# grep libreport /var/log/yum.log ... Dec 12 17:51:46 Installed: libreport-filesystem-2.0.8-3.fc16.x86_64 Dec 12 17:51:47 Updated: libreport-python-2.0.8-3.fc16.x86_64 Dec 12 17:51:48 Updated: libreport-2.0.8-3.fc16.x86_64 Dec 12 17:51:57 Updated: libreport-plugin-bugzilla-2.0.8-3.fc16.x86_64 Dec 12 17:51:57 Updated: libreport-plugin-logger-2.0.8-3.fc16.x86_64 Dec 12 17:51:58 Updated: libreport-plugin-kerneloops-2.0.8-3.fc16.x86_64 Dec 12 17:52:00 Updated: libreport-gtk-2.0.8-3.fc16.x86_64 Dec 12 17:52:02 Installed: libreport-plugin-bodhi-2.0.8-3.fc16.x86_64 Dec 12 17:52:03 Updated: libreport-newt-2.0.8-3.fc16.x86_64 Dec 12 17:52:03 Updated: libreport-plugin-reportuploader-2.0.8-3.fc16.x86_64
abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
reopening as per comment #8
(In reply to comment #8) > unfortunately, this doesn't seem to be fixed > > [kvolny@kvolny ~]$ rpm -q abrt-gui > abrt-gui-2.0.7-2.fc16.x86_64 > > at the Problem description screen, if I try to edit for example the "cmdline", > it seems that the value gets changed, but if I go next and then back, the > original value gets restored; also at the Review the data scrreen the cmdline > tab shows the original value instead of the one I've entered Can't reproduce. "cmdline" element can be edited. Some other fields, such as "executable", can't be - they show the behavior you described. In fact, there is a commented-out code which makes non-editable fields doing that: commit 8e369296f77d5a9d3e4dd146a77bdcc9ec1e8186 Author: Denys Vlasenko <dvlasenk> Date: Sat Jul 16 11:16:02 2011 +0200 wizard: save edited lines if they are EDITABLE Signed-off-by: Denys Vlasenko <dvlasenk> diff --git a/src/gui-wizard-gtk/wizard.c b/src/gui-wizard-gtk/wizard.c index bc50fd6..4cbac9a 100644 --- a/src/gui-wizard-gtk/wizard.c +++ b/src/gui-wizard-gtk/wizard.c @@ -505,7 +505,12 @@ static void tv_details_cursor_changed( struct problem_item *item = get_current_problem_item_or_NULL(tree_view, &item_name); g_free(item_name); - gboolean editable = (item && (item->flags & CD_FLAG_TXT) && !strchr(item->content, '\n')); + gboolean editable = (item + /* With this, copying of non-editable fields are more difficult */ + //&& (item->flags & CD_FLAG_ISEDITABLE) + && (item->flags & CD_FLAG_TXT) + && !strchr(item->content, '\n') + ); It was disabled because the ability to copy the (non-editable) strings to clipboard is also lost. What should we do?
(In reply to comment #13) > Can't reproduce. "cmdline" element can be edited. come to my cube :-) > Some other fields, such as "executable", can't be - they show the behavior you > described. ... > It was disabled because the ability to copy the (non-editable) strings to > clipboard is also lost. > > What should we do? fix the framework to allow copying also non-editable fields? watch the fields and change the displayed value back immediately, popping up some warning? differentiate fields that shouldn't be edited by some distinct graphics style, adding a (visible) note that editing such field will have no effect?
I believe that the initial problem is fixed the fields which are supposed to be editable are editable and the value is saved (e.g. cmdline) and users are presented with the window where they can see and edit all of the editable values. The second problem - that it's hard to distinguish between the editable and non-editable rows on the last page is for another bugzilla.