Bug 485746 - "Save As" for external files does not work as expected
Summary: "Save As" for external files does not work as expected
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.6   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.6 M5   Edit
Assignee: Andrey Loskutov CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-13 07:52 EST by Andrey Loskutov CLA
Modified: 2016-01-13 11:30 EST (History)
1 user (show)

See Also:

Attachments
comparison before/after the patch (128.59 KB, image/png)
2016-01-13 08:13 EST, Andrey Loskutov CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Loskutov CLA 2016-01-13 07:52:28 EST 
Open external text file in Eclipse.
"File->Save As"
A file save dialog is opened but the *current* directory (from the current file opened in the editor) is not selected and after changing the file name "OK" button is still disabled.

To save this file one has additionally find and select the parent directory, which is cumbersome.

We found this issue on gtk2-2.10.4-21.el5_7.7 (RHEL 5.8), where the attempt to hit "OK" results in immediate Eclipse crash. Fortunately, this is fixed in later GTK versions, the "Save" dialog simply do not enables OK button until parent directory is selected. 

This bug is reproducible on Eclipse from 3.6 to 4.6 on GTK2 and GTK3.

org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.performSaveAs() for external files does not properly set filter path in FileDialog. It must be a directory path, not the file path.

The fix is trivial, I have the patch.
Comment 1 Andrey Loskutov CLA 2016-01-13 08:13:09 EST 
Created attachment 259154 [details]
comparison before/after the patch
Comment 2 Eclipse Genie CLA 2016-01-13 08:14:21 EST 
New Gerrit change created: https://git.eclipse.org/r/64250
Comment 3 Andrey Loskutov CLA 2016-01-13 08:33:20 EST 
Just validated that the original issue seem to be GTK specific (have no Mac) - on Windows 10 the file dialog shows right directory in any case (with/without patch).
Comment 4 Dani Megert CLA 2016-01-13 10:28:27 EST 
(In reply to Andrey Loskutov from comment #3)
> Just validated that the original issue seem to be GTK specific (have no Mac)
> - on Windows 10 the file dialog shows right directory in any case
> (with/without patch).

Moving to SWT.
Comment 5 Andrey Loskutov CLA 2016-01-13 10:47:08 EST 
(In reply to Dani Megert from comment #4)
> (In reply to Andrey Loskutov from comment #3)
> > Just validated that the original issue seem to be GTK specific (have no Mac)
> > - on Windows 10 the file dialog shows right directory in any case
> > (with/without patch).
> 
> Moving to SWT.

Dani, FileDialog states in the javadoc, that the filter path argument must be a directory path. Here the client (editor) clearly violates this. Should SWT now make a breaking change and throw exceptions if this doesn't match, or should SWT parse and modify given argument, trying to resolve the path against file system? Also set/get will be not symmetrical anymore?
Comment 6 Dani Megert CLA 2016-01-13 11:23:18 EST 
(In reply to Andrey Loskutov from comment #5)
> (In reply to Dani Megert from comment #4)
> > (In reply to Andrey Loskutov from comment #3)
> > > Just validated that the original issue seem to be GTK specific (have no Mac)
> > > - on Windows 10 the file dialog shows right directory in any case
> > > (with/without patch).
> > 
> > Moving to SWT.
> 
> Dani, FileDialog states in the javadoc, that the filter path argument must
> be a directory path. Here the client (editor) clearly violates this.

Sorry Andrey, I did not deeply look into it, just moved after I read "GTK specific".