Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 364738 - Content Types preference page: default encoding is a text field that is not checked against the supported encodings
Summary: Content Types preference page: default encoding is a text field that is not c...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.8 M7   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-24 12:10 EST by Helmut J. Haigermoser CLA
Modified: 2012-05-01 22:49 EDT (History)
2 users (show)

See Also:

Attachments
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 Helmut J. Haigermoser CLA 2011-11-24 12:10:12 EST 
Build Identifier: 

One can change the default encodings for file types within the preferences which is a nice feature. However, the user gets no assistance choosing the encoding, no feedback about unsupported encodings even so that setting an encoding "bogus" does work in the prefs page, but will bring up an error once that file type is opened in the editor..

Reproducible: Always

Steps to Reproduce:
1. Open prefs page: Content Types
2. Set the default encoding for <file type> to "bogus"
3. Open a <file type> file in the editor
Comment 1 Helmut J. Haigermoser CLA 2011-11-24 12:10:56 EST 
CQ:WIND00090301

*setting the Version to 3.7*
Comment 2 Dani Megert CLA 2011-11-28 04:31:48 EST 
We need to be careful here. The set of supported encodings is not fixed but depends on the JRE. Whether we should allow to enter an unsupported encoding is questionable but we must ensure that we don't destroy current values just because the current JRE doesn't know them.

I would not touch this.
Comment 3 Helmut J. Haigermoser CLA 2011-11-28 04:35:08 EST 
(In reply to comment #2)
> We need to be careful here. The set of supported encodings is not fixed but
> depends on the JRE. Whether we should allow to enter an unsupported encoding is
> questionable but we must ensure that we don't destroy current values just
> because the current JRE doesn't know them.
> 
> I would not touch this.

Hi Dani :)
Hm, I understand your POV. Instead of strict checking, as a very safe fix can we verify the encoding as it is entered and report something like this in the dialog via warning-type Label: 
"Warning: The entered encoding is not supported by your Java Runtime Environment. Editors will not be able to display files for this encoding, among other issue. Please verify the spelling of the encoding and the used JRE (<display some JRE details>) to make sure the encoding can be used.."


What do you think?
Helmut
Comment 4 Dani Megert CLA 2011-11-28 04:52:59 EST 
Sorry Helmut. I quickly checked the code and we already disallow to *enter* bad values in general (e.g. General > Workspace > Text file encoding). This just got lost for the content type encoding.
Comment 5 Helmut J. Haigermoser CLA 2011-11-28 04:55:44 EST 
(In reply to comment #4)
> Sorry Helmut. I quickly checked the code and we already disallow to *enter* bad
> values in general (e.g. General > Workspace > Text file encoding). This just
> got lost for the content type encoding.

Thanks for checking Dani! :)
Sounds like we have a plan, aligning the "type encoding" with the "text file encoding" seems to benefit all, consistency, accuracy and hely! :)

Helmut
Comment 7 Michael Rennie CLA 2012-05-01 22:22:36 EDT 
verified in:

Version: 4.2.0
Build id: I20120430-1800
Comment 8 Michael Rennie CLA 2012-05-01 22:49:06 EDT 
forgot to mention also verified in:

Version: 3.8.0
Build id: I20120430-2000