After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741928 - Inconsistent filename after cancelled open command
Inconsistent filename after cancelled open command
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: filediff
git master
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2014-12-23 22:05 UTC by Balint Reczey
Modified: 2014-12-29 22:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Balint Reczey 2014-12-23 22:05:54 UTC
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773839 :

On 12/23/2014 10:21 PM, Nico Rikken wrote:>
...
> Dear Maintainer,
> 
> Having a changed but unsaved file open, trying to change one of the shown files via the seggregated menu bar will display the 'Select a File' dialog to select a different file for that particular subview. Since a file has been changed, a dialog pops up 'Save changes to documents before closing?' with the options 'Close without Saving', 'Cancel', and 'Save'. Choosing 'Cancel' to abort the command will keep the same files to be opened, whilst it does now display the filename of the selected file originally intended to open (although the filename in the tab is still correct). I expect the displayed filename to correspond with the opened file (content).
> 
...

The problem is reproducible on latest master, too.
Comment 1 Balint Reczey 2014-12-23 22:07:05 UTC
Rewrapped:

> Having a changed but unsaved file open, trying to change one of the
> shown files via the seggregated menu bar will display the 'Select a
> File' dialog to select a different file for that particular subview.
> Since a file has been changed, a dialog pops up 'Save changes to
> documents before closing?' with the options 'Close without Saving',
> 'Cancel', and 'Save'. Choosing 'Cancel' to abort the command will
> keep the same files to be opened, whilst it does now display the
> filename of the selected file originally intended to open (although
> the filename in the tab is still correct). I expect the displayed
> filename to correspond with the opened file (content).
Comment 2 Kai Willadsen 2014-12-29 22:51:25 UTC
This is fixed in the 3.12 branch, and will be in the next release.

Thanks for the bug report.