Closed Bug 23943 Opened 25 years ago Closed 23 years ago

Recognize .js extension in the same class as .txt extension so that prefs.js in UTF-8 can be edited by Mozilla composer

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
All
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: momoi, Assigned: sfraser_bugs)

References

Details

(Keywords: helpwanted, intl) 

Currently we are not able to edit prefs.js easily when it contains 8-bit data and encoded in UTF-8.
There is not too many easy/handy UTF-8 editor and the need for editing non-ASCII data in
prefs.js is quite high, I believe.

We should enable it so that when we attemt to open a pref.js file with Mozilla composer, it would be
treated like a .txt file and actually is opened.
The need for this bug has been discussed in Bug 23268.
Assignee: beppe → sfraser
Target Milestone: M15
assigning this to sfraser, this seems like a basic requirement -- Simon, do you
have any suggestions on how to do this?
While we are at it, can we also add ".dtd" extension to the
list of extension types which canbe opened by Composer?
.dtd files are used in localization and can really use
a good UTF-8 editor.

One thing I would like to ask others on the CC line is
whether or not we should have Browser behave the same way with
regard to these extensions.
The way I see it is to treat the *.js ( *.dtd, *.properties, etc..) as plain
text file and use our converters to convert the text from native encoding into
UTF-8 or escape-unicode. In other word, the composer can open a file in either
HTML or non-HTML (== plain text) mode.
Status: NEW → ASSIGNED
Note bug 16699 which is related. Cc rpotts, who may have input on how to get .js
files treated as if they were text files.
David: can your MIME mapping stuff help here?

Nothing really to do with mime mapping ( and please use mimetypes rather than 
extensions) unless I am missing something. I don't know how the editor loads 
documents ( is it a doc loader or uri loader?) but I would think that you would 
just have to add a couple of case statements to the place where you handle html 
and text/plain. And for what is worth we should just load any of the text/* 
cases like plain text.

M16
Target Milestone: M15 → M16
M17
Target Milestone: M16 → M17
setting to future, this is a feature request
Target Milestone: M17 → Future
adding help wanted keyword
Keywords: helpwanted
Keywords: intl
What currently happens with .xml, .css, .xslt (or whatever), etc. here?  Should
they be added to the list to be opened as text?
IMO, whenever Composer encounters a type it doesn't recognize, it should treat 
it as plain text, or at least give the user an option of treating it as plain 
text.  Currently is says "this type of page can't be edited" and crashes 
Mozilla.
Adding myself to CC.
Bug will will get patches for this.
Depends on: 63515
*** Bug 76394 has been marked as a duplicate of this bug. ***
Fixes checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified in 9-24 Trunk Build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.