Closed Bug 23943 Opened 25 years ago Closed 24 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)

All
Other
defect

Tracking

()

VERIFIED FIXED
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: 24 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.