I thought there was a bug on this, but I could not find it anywhere. mark as dupe if i just missed it. It would be nice if Mozilla had the NS4.x ability to open an external editor for editing HTML source and image editing. In 4.x the prefs are under Composer. We all have our favoriate ASCII text editors UltraEdit in my case. When I want to edit the HTML source it would take you all a long long time to duplicate the features in UltraEdit. So why not just give us a linke to external editors. Not sure what all is involved, but this could be an easy way to get out of some of bug 14526. If you all run out of time.

RFE->M20

Adding helpwanted keyword and 4xp keyword, I hope you don't mind.... This feature is in Netscape 4.x and is very nice when you want to edit the source in your fav editor. As it is n 4.x I thought 4xp keyword was important and helpwated in case someone else thinks they could pull this off. Of course I think bug 28792 "publishing facility in the editor" is more important. However this bug/feature might be easier to implement by someone else.

CCing Hurricane (rcassin@supernova.org) He may try this out /me hopes

*** Bug 52586 has been marked as a duplicate of this bug. ***

See also: bug 8589 let "view source" open external editor. bug 47147 "edit image" with external editor. As I understand it, this rfe is just for composer.

*** Bug 63790 has been marked as a duplicate of this bug. ***

*** Bug 69329 has been marked as a duplicate of this bug. ***

*** Bug 93946 has been marked as a duplicate of this bug. ***

-->brade

spam composer change

See also bug 103767, [RFE] Key to start $EDITOR for <textarea> (external text editor).

Indeed, the View->Page Source window is nice enough to not warrant any additional re-inventing of the wheel, but the ability to call a user-specified external application instead would be yet nicer (substantially so, for those of us who use PSGML). And if the functionality exists to call an external viewer/editor for HTML source, Messenger could also use it for composing mail. Or should that be filed (or has been already?) as a separate RFE?

Any chance of getting this feature into 1.0? And would it be much more than a UI pref? Many web developers I know (myself included) consider this the most missed feature from IE that Moz is lacking. (My girlfriend won't even use Moz because of it!) Just hopeful, although I know crunch time is on...

The keyword above ("helpwanted") means that no one is really working on this bug yet (or if they are they haven't said so publicly). Why not use File > Edit Page and use Composer's HTML Source view? If you have problems with that, I'd love to address those (in separate bugs). Thanks!

Isn't this bug a dup or very similar to bug 13474 ?

Regarding comment <a href="#c14">Comment #14</a> above, the issue is not really a bug regarding Composer. This bug is about being able to use whatever editor/authoring tool the user wants to use, for reasons of power, accessibility or preference. However, I agree with #15 above that this bug appears to be a duplicate of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=13474">Bug 13474</a>. Perhaps this one should be closed?

My understanding of bug 13474 is that it is specific to editing textarea contents. This bug is for editing the entire html source of a web page. The workaround in comment 14 is the workaround. Right now, I have no plans to work on this feature given the workaround.

-->

The Comment #14 From brade@netscape.com in this bug looks intressting: I try hard (for a long time) to motivate SOMEBODY to make the source view of composer useable for authors with needs for hand-formated html source code (even the head section). Due to several bugs (example: http://bugzilla.mozilla.org/show_bug.cgi?id=97278) this is not possible since version 0.9.7. Now I think SOMEBODY==brade@netscape.com, because he wrote "... If you have problems with that, I'd love to address those (in separate bugs).". Mozilla is not useable for non-trivial html code, so please support an external editor or make the html-source view useable for such tasks.

It would be nice to assign my external HTML editor, which is a text editor, to the browser so that each time I upgrade the browser, it will not take over this editors assignment to the Edit command on HTML and SHTML files. I have to manually assign this program every time it is changed by Mozilla on an upgrade install.

Adding myself to CC list. Please change this bug's component to ViewSource; this bug has SFA to do with Composer. Please change this bug's severity to major. I'm sorry, but this is not a RFE - it's a BUG! Loads of people want to be able to choose their page source editor, and use IE because it allows them to. Not being able to do it in Mozilla simply sucks.

*** Bug 241441 has been marked as a duplicate of this bug. ***

(In reply to comment #5) > As I understand it, this rfe is just for composer. As I understand it, this rfe is to activate something *other* than composer when File|Edit Page is selected from the browser menu -- as noted in comment 16. As such, it is filed under the wrong component. I suggest that, on Windows systems, Mozilla provide a means to fall back on the system-defined HTML editor. This is located in the registry, at HKCU\Software\Microsoft\Internet Explorer\Default HTML Editor and the selection can be viewed in the Programs tab of the Internet Options control panel. (Changing this setting in the control panel also changes the association of the Edit command in the context menu of Windows Explorer, something "Scott" [comment 20] might like to know.) I don't know how, or whether, the other OS's define a system-wide editor; but ideally, a preference UI would be provided somewhere like: Edit pages using ( ) Mozilla Composer ( ) Default editor (o) Other: myeditor.exe [Browse] For systems not supporting a default editor, that middle "default" selection could be disabled or, better, hidden. This could be accompanied by a button, "Make Mozilla the default HTML editor", in which case the "Make Mozilla the default browser" action ought to be tweaked to *not* set Mozilla as the default editor, controlled separately (bug 196522). See also the Firefox bug 172817, which seems to be half about a feature like this bug's and half about a feature like bug 8589.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614