Opening this bug as the user error behaviour mentioned in bug 99639 only happens in Windows and not Linux and they should be the same. Steps 1. Open Writer 2. Ctrl + S 3. Replace the file extension .odt with .docx and dont change the 'save as type' drop down from its default 'ODF Text Document...' entry 4. File is saved in odf format
This is basically bug 93199, right?
That's how Linux works. You can label a file foo.doc.odt and the user is supposed to be smart enough to work without automatic adjustments. WF in my opinion.
I've seen this inconsistency in the past... on Linux the export change to .odt if I change the name. However, on Windows, the output name will be foo.odt.xxx. From my point of view, it's a bug as the behaviour is inconsistent across platforms.
(In reply to Xisco Faulí from comment #3) > From my point of view, it's a bug as the behaviour is inconsistent across > platforms. It's how the platforms work, inconsistently. Windows hides the file extension and you see foo.doc while the actual extension is .odt. On the other hand, in case of raster graphics no one cares if a bmp file is called png because the application detects the format not trusting on the filename. And LibreOffice is capable of that too.
(In reply to Aron Budea from comment #1) > This is basically bug 93199, right? Guess it is. (In reply to Heiko Tietze from comment #4) > It's how the platforms work, inconsistently. Doesnt mean that we cant fix this issue specifically to Windows for the save dialog, as we have users who are using LO cross-platform and falling over this issue. On Windows, i can change the filetype of the open dialog to only show .docx files, but if i type the name of a .odt file in the filename field, it will pick it, though it still tries to load it as a .docx file. ;D > Windows hides the file > extension and you see foo.doc while the actual extension is .odt. On the > other hand, in case of raster graphics no one cares if a bmp file is called > png because the application detects the format not trusting on the filename. > And LibreOffice is capable of that too. Hiding of file extensions isnt relevant, as you can easily enable the showing of file extensions.
*** Bug 115229 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #6) > *** Bug 115229 has been marked as a duplicate of this bug. *** Sorry, this was a mistake as Jay's report is against Windows.
Let's put this one to NEW
Dear Yousuf Philips (jay) (retired), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still there in Version: 6.0.7.3 and still <really> irritating!
Second WF suggested in comment 2.
(In reply to Mike Kaganski from comment #11) > Second WF suggested in comment 2. Then let's do it.
(In reply to Heiko Tietze from comment #2) > That's how Linux works. You can label a file foo.doc.odt and the user is > supposed to be smart enough to work without automatic adjustments. WF in my > opinion. I'd say this is more of a convenience feature than being "smart enough." You're entering a file name already, and you could just type a few more characters instead of opening the dropdown, finding the entry you're looking for and clicking on it. Then again, surely there'd be things to keep in mind, like prominently notifying the user in what format the file is actually saved in.
(In reply to Aron Budea from comment #13) I suppose that we must try hard to follow OS/environment conventions as much as we can. And unless we use our own file dialogs, the dialogs provided by shell must behave just as in other applications (or rather as shell designers intended them to behave). On Windows, that is according to how MS intends it; KDE or Gnome have own vision... I suppose that any change in the behaviour of such things to be custom to LO is bad.
(In reply to Mike Kaganski from comment #14) I'd doubt any OS convention exists on adding two extensions to a file (which isn't something a user would normally do), thus I don't think being lenient about this would be unreasonable.