Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 97284 - allow page to make arbitrary elements user-editable in browser (contentEditable attribute)
: allow page to make arbitrary elements user-editable in browser (contentEditab...
Status: RESOLVED DUPLICATE of bug 237964
[Hixie-P5] [Hixie-CSSUI2] EMBEDDING
: css-moz, ecommerce, topembed-
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: -- enhancement with 128 votes (vote)
: mozilla1.3beta
Assigned To: Charles Manske
: sujay
: Jet Villegas (:jet)
: 122158 147575 150609 151967 163249 166987 177128 191833 209553 249692 322335 340375 (view as bug list)
Depends on:
Blocks: oscom 174709 grouper
  Show dependency treegraph
Reported: 2001-08-28 06:00 PDT by Daniel Glazman (:glazou)
Modified: 2007-07-13 23:40 PDT (History)
119 users (show)
asa: blocking1.3a-
asa: blocking1.3b-
brade: blocking1.3-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Example of Implemented Editor in IE (23.10 KB, text/html)
2002-03-07 17:00 PST, Michael Stearne
no flags Details
Discussion on netscape.public.mozilla.wishlist (20.46 KB, text/html)
2002-04-17 07:06 PDT, Jan Frederik Solem
no flags Details
Baseline content editable features list (272 bytes, text/plain)
2002-10-09 18:36 PDT, Susie Wyshak
no flags Details
2 extra wishlist items (34 bytes, text/plain)
2002-10-10 01:39 PDT, seb bacon
no flags Details
contentEditable API (1018 bytes, text/plain)
2002-10-10 08:33 PDT, Scott Blanchard
no flags Details
contentEditable wishlist (2.21 KB, text/html)
2002-10-10 08:44 PDT, bugzilla
no flags Details
contentEditable wishlist by Erik Arviddson (1.32 KB, text/plain)
2002-10-10 11:48 PDT, Erik Arvidsson
no flags Details
contentEditable wishlist by Erik Arvidsson (1.32 KB, text/plain)
2002-10-10 11:48 PDT, Erik Arvidsson
no flags Details
GED's Wishlist for Moz Editable content (1.75 KB, text/plain)
2002-10-10 14:33 PDT, Garth Dahlstrom
no flags Details
Requirements for in-browser, user-editable DOM nodes. (1.57 KB, text/html)
2002-10-10 20:35 PDT, Mike Gratton
no flags Details
some security implications of scriptable copy/paste (2.63 KB, text/html)
2002-11-05 00:52 PST, Jesse Ruderman
no flags Details
some security implications of scriptable copy/paste (2.63 KB, text/html)
2002-11-05 00:58 PST, Jesse Ruderman
no flags Details

Description Daniel Glazman (:glazou) 2001-08-28 06:00:45 PDT
I think we could add in the future a wonderful feature to the product : allow
any element in a browsed document to become editable. For instance, allow user
to directly modify in the browser the textual contents of a paragraph, or even
add elements and style them. Used in conjunction with DOM Load & Save, that
could be a killing app, letting us put two feet instead of one finger nail into
web publishing and/or collaborative edition.

I found that Microsoft started doing something like this during the CSS WG
meeting in Cleveland in 1999 when the first mention of the |isContentEditable|
proprietary extension to js appeared on their developer's web site. See below
for (a) technical data about the feature (b) a demo you should **really** try
with IE5.5 or higher.

We have a good browser, a powerful DOM, a clever editor based on the browser and
the DOM. It should be possible, at quite low cost, to add such a feature to
our product (me is perhaps dreaming at loud but, hey, that's a part of what I
am paid for, right ?-)


Comment 1 Markus Gerstel 2001-08-28 06:19:44 PDT
We already have this, it is called Bug 96604 =)
Comment 2 Simon Fraser 2001-08-28 11:14:52 PDT
This should be done in a way that embedders can use it.

The real issue here is user experience. How do you indicate to the user that 
certain parts of a document are editable? How do you manage focus and keyboard 
navigability of editable elements?

I think, if we are to do this, it needs to be keyed off of CSS (-moz-editable or 
Comment 3 David Hyatt 2001-08-28 11:33:39 PDT
This is what hixie has proposed in his CSS UI draft.  A property called
user-can-edit, I think.  (Goes along with user-can-focus, etc.)
Comment 4 Pierre Saslawsky 2001-08-28 16:03:58 PDT
Simon: in my opinion, the only feedback the browser should give is changing the 
mouse cursor.  The rest of the UI should be the responsibility of the server. The 
'contentEditable' elements should be out of the tab list and without focus 
indication (a bit like word processors: there is no focus and you cannot tab from 
a paragraph to the next)

For instance in a groupware application, the host would serve documents depending 
on the user access level that could be read-only, partially modifiable or fully 
editable.  The author will have to decide what visual feedback better represents 
the user access level, and it is nice to imagine that the whole mechanism (making 
things modifiable and providing feedback) can be implemented by a simple switch 
of stylesheet depending on the user.
Comment 5 Syd Logan 2001-09-12 13:29:59 PDT
spam composer change
Comment 6 Arnoud Berendsen 2001-10-10 07:58:17 PDT
I think what this RFE is talking about is basically what IE does with <DIV
CONTENTEDITABLE>, but to implement it on a broader scale. This would indeed be a
definate IE killer. Implementing a CMS would be several orders of magnitude
easier with this!

If this is so, why is this in de Editor: Composer component?
Comment 7 Daniel Glazman (:glazou) 2001-10-10 08:02:40 PDT
Because the Editor component has been divided in two after the bug was filed,
that's all.
Comment 8 jp 2001-12-14 01:12:42 PST
Original question send to Sujay:

Is there, or going to be a way to access the composer components via JavaScript
from html documents ?
Like the execCommand("command") and .contentEditable='true' methods used by
Internet Explorer 5.5 ?
These commands are the remains of what used to be Frontpage Express which have
become accessable via 
Jscript, VBscript, Visual Basic and C++.

added comments:
Currently we're using the IE components as a clientside browserbased content
Editor. Developers set the editability 'freedom' via contentEditable. Editing is
done via Wysiwyg interface run via JScript execCommand('commandname').
Edited webpages are submitted to a database which does the actual content
management. Content management is done via database.
Comment 9 Alfonso Martinez 2002-01-28 05:36:07 PST
*** Bug 122158 has been marked as a duplicate of this bug. ***
Comment 10 kaldari 2002-01-28 08:17:47 PST
If this functionality is ever implemented, I would suggest trying to match 
Micro$oft's syntax whenever possible. Not because Micro$oft's syntax is 
especially great, but simply because hundreds of web applications are 
currently being written with it.
Comment 11 Daniel Glazman (:glazou) 2002-01-28 08:25:31 PST
I have, unfortunately, to agree with last comment...
Comment 12 Alfonso Martinez 2002-01-28 08:40:57 PST
The syntax doesn't have to be the same. 
Currently working systems that rely on this feature will use other IE centric
features as document.all, filters, etc... so it's not likely that just by adding
some of the syntax to deal with the editor it will automagically work in every
CMS around.

What's most likely is that if the people is interested in support Mozilla then
they will add a second page and will redirect the user according to the browser,
and to design that second page they will use some sample that in the future will
be developed to test the implementation by Mozilla developers.

So there's no real reason to try and force the development of this feature to be
guided by the current syntax of IE. It can use whatever the Mozilla's developers
like. Just do it wisely and everybody will be happy.
Comment 13 Michael Stearne 2002-01-29 14:10:51 PST
Is this actively being worked on?  

As for IE syntax, etc.  It would help if it was maybe similar, but I don't think
it's necessary to be exact.  It may be good to even implement just the methods
used in the example for this bug.  My reasoning is this:

If a developer of an existing IE application sees that the example above works,
they may consider "supporting" Moz.  If they do support it, they will maybe read
a little more to get the rest of the functionality working on IE and NS.  

Unfortunately it's too easy to slap a "IE Only" label on and app.  So this
halfway compromise may get Moz's foot in the door.

BTW the editing stuff in IE doesn't even work on the Mac side, which is typical.
 At least we know if it's done in Mozilla it will work everywhere.
Comment 14 Charles Manske 2002-01-30 09:07:04 PST
Yes, I am very interested in support the MS interface. We have to see how it fits 
in with our current embedding re-architecture work.
Comment 15 Michael Stearne 2002-02-07 13:01:58 PST
The most complete implementation of this feature in IE can be seen at  Something that looks very
similar to this is what is used in Hotmail.  If this could be implemented I am
sure that is most of the features that are necessary.
Comment 16 Erik Arvidsson 2002-02-07 14:33:32 PST
To call this "the most complete" is an insult to everyone out there who have 
made superior editors compared to this one.

Basically Mozilla has all the features needed to support this the only thing 
to do is to bring back the possibility to edit the document using the 
keyboard. This was available in early previews of Gecko. I have no idea why 
this was removed.

The range methods of DOM Level2 Ranges would allow the developer to insert 
images and change formats and all that stuff.
Comment 17 Michael Stearne 2002-02-07 14:40:38 PST
What I meant rather, was this is as complete as I've seen an implementation of
this particular technology that is available in IE.  I am not talking about
having an editor as complete as Composer embedded in the page, but more a basic
editor so the user can have a WYSIWYG editor within the page, but those changes
they made could still be submitted as a form element.  

Comment 18 Charles Manske 2002-02-07 15:34:46 PST
After a review of the embedding work being done by mjudge, we are confident that
we will be able to support this, but probably not for 1.0.
Comment 19 Michael Stearne 2002-02-08 07:28:57 PST
Whoo Hoo! A target is set after just a little talking to the developers.  This
is why Open Source developer is great.
Comment 20 Jaro v. Flocken 2002-03-07 06:20:09 PST
In the nightly builds there is a menu item called "Editable mode" - si it
possible to add a javascript method on frames/iframes that toggles/switches this

IMHO it's not a big deal to add this feature and it give us a lot. Using DOM/js
a much better (say HTML4.x compilant) editor component that the IE Frontpage toy
could be easily done. Please!

Comment 21 Kathleen Brade 2002-03-07 07:19:22 PST
Jaro v. Flocken--I think it's a great idea too.  We would love it if you or
someone else would submit a patch to address this rfe.
Comment 22 Jaro v. Flocken 2002-03-07 07:41:26 PST
I'm a very poor C++ programmer, more into the HTML /java and javascript stuff.
Howerver I could assist a coder during the implementaion (building a sample
Editor app etc.)

Comment 23 Michael Stearne 2002-03-07 08:43:20 PST
What do you mean actually? A javascript hook to open the current page in
Composer, but within an iframe in a certain page (with or without the menubar)? 

This could be a good idea, but as is illustrated in the example there should be
a way for the HTML on that page to be "captured", that is, allow the
iFrame.body.innerHTML (and innerText) to be assigned to a JS variable in the
opener page.  This way the edited document could be sent back to the server as
raw HTML to be stored in a database, file, etc.

Also, just editing the whole page would be no good.  It would be better to
specify what would be edited, meaning

Comment 24 Jaro v. Flocken 2002-03-07 09:09:10 PST
In XUL you can add a simple <editor> Tag to get a WYSIWYG Editr area. 
At the moment it stops at the sandbox - if one tries to pull such a XUL document
from another location or using http: instead of chrome: a js security exception
will be fired.

A simple solution is indeed switching a completed document object into the
editor mode because we con use frames or - much better: iframe. The source
attribut of the iframe tag gets another document, this can be retrieved with
*.body.innerHTML or whatever (I'm sure there is a way to get the complete html

Please correct me if I completly wrong :-)

Comment 25 Simon Fraser 2002-03-07 11:30:19 PST
What this bug refers to is not using <editor> or <HTMLArea> or anything. It's
about allowing arbitrary content in a web page to be editable. Imagine:

<p>Hello there. Type something here:</p>
<div editable="true">
Type here...
Comment 26 Erik Arvidsson 2002-03-07 11:42:04 PST
I thought that the Css3 proposed properties user-input and/or user-modify are 
supposed to do these. (Maybe user-select and user-focus as well in some way?)

These seems to be implemented using -moz-user-input and -moz-user-modify but 
these only work for input[type=text] and textarea.
Comment 27 Joseph Delaney 2002-03-07 12:49:31 PST
Where do you see a menu item for "Editable mode"?  I just checked both the
MacOSX and Windows builds for today, and cannot find it. 

For what it is worth, I would love to see this feature and would immediately use
it, but the real issue for me is to be able to submit edited HTML content in a
form. So if it worked completely differently that would be OK too - for
instance, click a link and a page opens in Composer, click the Composer "save"
button and the HTML gets written to a form value, click the "Submit" button to
send it to wherever. Whether the page is edited within an iframe or in a
separate composer window is immaterial (for me at least). 
Comment 28 Michael Stearne 2002-03-07 13:27:09 PST
This is my exact need also.  I think the menu item he was talking about is Edit
Page.  I too have an urgent need as we are releasing a new feature as a major
part of out application and right now it's an IE only feature.
Comment 29 Jaro v. Flocken 2002-03-07 14:25:17 PST
A <div> would be also great, ther is no need for proprietray tag's here, I just
tried to explain what I mean. I definately don't mean "auto open" a page in
Composer, it's more an embedded widget or area (call it what you like to) that
enables editing the innerHTML (or source in case of IFrame) in a WYSIWYG style,
excatly what <editor> is doing in the composer XUL File.

Many users want to edit parts of pages in content managment environments or
bulletin boards in the same way like a textprocessor (say Word or Staroffice here).

Another benefit is storing the edited content using any POST method, I doubt
thta this is possible/wished in Composer.

Comment 30 Michael Stearne 2002-03-07 15:03:18 PST
Well, that's what the original reaquest is for, exactly what you described.  I
thought you were originally suggesting a temporary work around until the full
fix is implemented.  As of right now, I think the leap from adding the <editor>
tag in XUL to implementing all of that in a <div>  is more diffucult then it
seems, because of code issues, not architecture.

Comment 31 Bart Mortelmans 2002-03-07 15:32:50 PST
I've been reading things about just using composer(-like inline elements),
complete with buttons and all. I thing it would be really important to be able
to control the mark-up with javascript. Sure, it would be easy if we (the
webdesigners) don't have to add buttons and javascript anymore, but it would
certainly limit the fexibility.
One thing I don't see you do without javascript being able to control the text
is add an image (one that's on the server or that can be uploaded by the user
Comment 32 Michael Stearne 2002-03-07 17:00:06 PST
Created attachment 73094 [details]
Example of Implemented Editor in IE

This is the code currently in use by our company to implement this
functionality in IE.
Comment 33 rubydoo123 2002-03-08 12:07:24 PST
removing myself from the cc list
Comment 34 Daniel Glazman (:glazou) 2002-03-14 02:46:39 PST : the "Editor mode" menu item is not in the browser but
   in viewer ; on windows, try mozilla\dist\win32_d.obj\bin\viewer

But that's not, as Simon pointed it out, the main purpose of the current bug.
Interesting idea, though. Btw, that menu item does not "toggle" editor mode, it
turns editor mode on, that's all. There is no way in viewer to turn it off.
Comment 35 John Mora 2002-03-26 13:34:21 PST
Not allowing arbitrary elements to become editable is totally sucking the
monster bug wang. This bug being fixed would be of great use to not only myself,
but developers around the world. I will feed you beer by the bucket if some kind
heart will consider implementing|correcting this.
Comment 36 Jesse Ruderman 2002-04-13 02:03:49 PDT
See also:
bug  96392 [RFE] Exposing HTML Editor commands to Browser Dom
bug 130796 HTML editor for <textarea> (HTMLArea)

I think both should be duped to this bug or wontfixed in favor of this bug.
Comment 37 Simon Fraser 2002-04-15 10:50:23 PDT
This is *not* a dup of bug 130796. They are rather different issues. I think bug
96392 should be dupped against bug 130796.
Comment 38 Jesse Ruderman 2002-04-15 12:57:15 PDT
Simon, can you explain why you think they aren't dups of this bug and why you
think they're dups of each other?
Comment 39 Simon Fraser 2002-04-15 13:53:33 PDT
Bug 130796 is about <htmlarea>, which is an HTML-capable <textarea> (though
closer to an editable <iframe> in implementation). HTML editing is limited to a
specific frame in the page.

This bug, and bug 96392, are about making arbitrary parts of the content of a
document editable via script, or CSS attributes. The implementation would be
Comment 40 JT Smith 2002-04-15 23:19:00 PDT
I'm the lead programmer on a popular OS CMS called WebGUI ( I
can't even fathom the amount of effort you guys have already put into Mozilla,
but I can tell you that in the CMS world, there is no higher priority than
trying to find a cross-platform inline editor. I can tell you that you do not
have to strive for compliance with IE or Opera or any other browser provided
that the functionality works on all versions of Mozilla. 

I can also tell you that IE will immediately be replaced by Mozilla as the
browser of choice by all of the WebGUI users (including some Fortune 500
companies) if this functionality were implemented. There is no hotter topic than
CMS as far as browsers are concerned in any company we've dealt with. And every
one of them wants to be able to publish content in their browsers from Windows,
Mac, Linux, and Solaris desktops scattered throughout the company.

There are a couple of commercial companies out there trying to make this work
(as java plugins), but we've purchased both of them and they both fail in many

No matter which of the bugs (listed above or this one) you follow as an
implementation method, you will knock IE on it's can, as long as the resultant
HTML snippet can be passed back through a form.

I cannot wait to see this type of functionality implemented.
Comment 41 saari (gone) 2002-04-16 16:54:21 PDT
JT Smith, would an editable iframe be good enough, or do you really need
aribitrary elements in a page to be editable? Those are pretty different things,
from our perspective anyway.

I'm thinking that if the Java solutions are an option then an editable iframe
would be good too.
Comment 42 JT Smith 2002-04-16 17:37:42 PDT
An editable IFRAME may do the trick, but I think there's really more to it than
that. We need methods through javascript to be determine what is highlighted,
perform some manipulation on that (like add style information), and then replace
the highlighted text with our new text.

There is a great open source DHTML editor here:
that you could take a look at. However, they're using some other IE only
functionality like modal windows.

We have another editor that we got from some DHTML site. It works very well too
and doesn't appear to use as much IE specific code. You can see it in action if
you go here: and
you can download the source from here:

However, the thing that I think would be absolutely ideal would be to see
Composer loaded as a form element (instead of a textarea). That way users would
have all the power of Composer at their fingertips, and CMS developers could
integrate the output of composer into their form post without any trouble.
Comment 43 JT Smith 2002-04-16 17:43:18 PDT
There are a couple other advantages to using Composer as a form element that I
forgot to mention.

1) If all that power were implemented, there'd be no reason to reinvent the
wheel. That way developers could spend their time working on something that
hadn't already been done.

2) It would give you an edge over Internet Explorer (until they copied it by
creating a form element that used Front Page).

3) It would be fast as hell because there's nothing else to download (unlike
java and dhtml based solutions).
Comment 44 saari (gone) 2002-04-16 17:53:01 PDT
Composer as a form element could be a option. Composer today works by making a
document editable, but all the editing UI is wrapping that editable document. 
Another option, one that was explored in the now defunct 5.0 codebase was to
have floating editing palette available that we implemented. Like you said, this
has download speed advantages among others.

However, what some people want is the IE style ability to create your own
editing UI with HTML that listens for selection as you described. The core
functionality could be the same, but we'd have to allow custom or canned UI
selection somehow. 

This is one of the big things both internal and external customers have asked
for post 1.0, so now is the time to weigh in on exactly what you need, and want
(noting that they can be different things).
Comment 45 JT Smith 2002-04-16 18:08:08 PDT
I work mostly on the server side components of WebGUI. I've asked our resident
DOM/JavaScript guru to put together a list of what he'd need to make things work
properly if we built our own editor. I'll post that list as soon as he gets it
to me (a day or two). 

I have to say though, that even with the functionality added to create our own
editor, I think I'd rather use composer as a form element, because it would be a
monsterous effort to try and recreate the power of composer in our own editor.
Then again, if we could just extend/alter one of the open source editors that I
mentioned previously, perhaps it wouldn't be so big a deal.
Comment 46 Michael Stearne 2002-04-16 18:36:50 PDT
If you view the attachment to this bug
(, IE 5.5+), you
will see how we implemented the editor.  One feature that was hard to do for us
was to allow certain text to be inserted at caret via a double-click with the
.value (or innerText) of some other element in the page.  This is an important
feature for us because we would like to use Moz as an HTML editor, mainly for
creating form letter templates that then get values swapped in for keywords. 
This would eliminate the need for an external word processor (Word,etc.) and
keep out application entirely browser-based AND cross platform (all this IE
stuff only works IE for Windows).

So we are less interested in customization of UI and more with solid Javascript
hooks into the embedded Composer element, especially the ability to figure out
where the caret position is and insert something (text, HTML) there.
Comment 47 Laurens van den Oever 2002-04-17 02:41:31 PDT
As mentioned before, there are two different features being discussed here.

1. The editable IFRAME or <HTMLAREA>. This would be a nice feature if it has a 
toolbar. It would make a great rich text input field for forums etc. IE 
(windows only) has this feature (DHTML Editing Component) since version 5.0 (or 
as plugin to 4.0) and it is used in various input forms. See for instance for an editor demo using that feature (IE 5.0+ on windows 
only). The site is in dutch, click in "demostratie" for a demo, click on "log 
in" to activate the editor and on the wrench to start editing.

2. The ability to make abritrary elements editable. IE (windows only) has this 
feature (contentEditable="true") since version 5.5. This feature really moves 
browser technology out of the input form era and paves the way for real 
applications in the browser. See for instance an editor comparable to ecop 
using contentEditable="true" at (IE 
5.5+ on windows only). Click on one of the images to edit that page.

As i said, contentEditable paves the way for real applications. An other 
example which shows some of the power of contentEditable is Xopus. Xopus is a 
browser based in-place WYSIWYG XML editor. For a demo see: (again: IE 5.5+ on windows only)

Implementing just an editable IFRAME would limit us to input forms.

Implementing contentEditable in the same way as it is done in IE would make it 
possible to make these applications, and applications we haven't even thought 
of, available for Mozilla users.
Comment 48 Jan Frederik Solem 2002-04-17 07:06:28 PDT
Created attachment 79617 [details]
Discussion on netscape.public.mozilla.wishlist
Comment 49 Hixie (not reading bugmail) 2002-04-17 15:51:29 PDT
Er. Apparently the '-moz-user-input' property already works to some extent.
Comment 50 Jesse Ruderman 2002-04-27 21:35:08 PDT
Hixie: I can't figure out how to use -moz-user-input (and -moz-user-modify and
-moz-user-focus) to let a visitor edit a page.  Do you know how?
Comment 51 Esben Maaløe 2002-05-09 16:12:25 PDT
PLEASE PLEASE PLEASE - just do it!  Do it with a <HTMLEDIT> tag, do it by making
any element editable - do it with propriaty extensions of HTML - do it by
emulating IE - Do it ever which way - But for the sake of having a truly viable
alternative to IE, and for the love of the Internet - DO IT - Please.

How can I as a web-developer convince my marketing/administration/power guys
that Moz is the way to go, when they cannot use the fancy editor they are used
to from Hotmail, Yahooo mail etc? To them that spells 'inferiour browser' and I
can whine for days about platform-independance, standards conformance etc. What
do they care? They all use windows anyway.

The Internet is moving from a Server/Client model to a P2P model - Still more
and more websites become dynamic, and less tech-savy users are beginning to
provide content on a massive scale. CMS is THE THING on the WWW part of the
Internet right now (much like real P2P is the buzz at the moment), people are
Blogging, chatting and providing content like never before. I've just
implemented a cool editor in IE - and it carves holes in my soul that I can't do
it in Mozilla but have to resort to a textarea and bbcode. My mother will never
get bbcode, and she'll never understand the connection between raw text with
some strange markings in it and a nicely formatted piece of text.

Listen to JT Smith - he has got more than just a point

I beg you - please do it - do it for the sake of Linux/Mac users, for the sake
of my mother, do it to bash IE and all of it's security holes, do it to help rid
us all from the Microsoft way of thinking, do it for your own reasons. 

I swear that if I could - I would, but I am not a C++ programmer, merely a
humble web-developer.
Comment 52 Esben Maaløe 2002-05-10 09:11:13 PDT
One more thing

All this XUL business is really great, and extending the editor is great too -
but first things first. If Mozilla is going to make it, it has to cater for the
users, then the web-developers and then the application-developers, not the
other way around.

You cannot underestimate 'sex-appeal' in the user-interface when it comes to
swaying users, and a textarea just isn't very sexy!
Comment 53 Tony Gorman 2002-05-11 16:33:25 PDT
Just to add my 2ps worth to this  RFE. 

I have been advocating Mozilla over IE for 2 years now at every opportunity.
Perhaps the most common request I ever get hit with is - give us an alternative
to MSHTML - we want to do rich HTML editing via a web page and post back the
content - but without IE.

This feature would truly, truly rock my world and the worlds of shitloads of
other people. I have been playing with SOAP im Mozilla and the GoogleAPI all day
and it is superb. Now if only I could  press "Save HTML" and get my rich WYSIWYG
HTML  saving via a SOAP call to a backend. How cool would that be? 
Comment 54 Jaro v. Flocken 2002-05-11 16:49:17 PDT
Hi again,

I don't wanna start a flame war but using the DHTML Editor of IXplorer is a pain
in the ass, nice html code will be scambled without logic and for no reason.

But, as Esben pointed out: Users first - in my case customers first. And they
make changes on a html page like writing a letter on a Word(processor).

I love mozilla and still dream about such a tool for moz. I strongly feel that
it can fight back some lost market share just about this feature (Mac users!)

Again: Most of the fuctionallity is already build in - so it cannot be such a
big deal. Please!

Just my 2c, Jaro
Comment 55 Daniel Glazman (:glazou) 2002-05-13 01:51:35 PDT
Hej Esben,

> You cannot underestimate 'sex-appeal' in the user-interface when it comes to
> swaying users, and a textarea just isn't very sexy!

Well we can. It's just a question of priorities. (before flaming me, please check
that I am the reporter of this bug). The list of priorities and the prioritization
(we need to invent P12N acronym for this word :-) of these priorities made it
impossible to have the current bug on top of list.
Comment 56 fcu-moz 2002-05-13 02:02:22 PDT
if there is a commercial need for this feature i think we could go and 'sponsor'
a developer to build what is needed (i saw this happening with the roaming
Comment 57 Esben Maaløe 2002-05-13 07:03:18 PDT
Hey Daniel!
>Well we can. It's just a question of priorities. (before flaming me, please check
that I am the reporter of this bug). 

Oh - I never flame people :) Unless, of course, they want me to. RC2 is
wonderful - it's slimmer, faster and generally a darling in all respects. IE6
still makes a big white flash when rendering a new page - sometimes with Moz -
you have to actually read the page to be sure it changed :) And the javascript
engine is a little wonder. I am doing rather javascript intensive project and it
is IE 5.5 and IE 6 that comes with strange errors all the time, Moz just does
what I tell it to do :) 

Sometimes IE6 and less just plainly "forgets" to load something that you wan't
included, and it changes readystate of elements before they are ready -
sometimes (but not all of the time ) it fires onload before the page-elements
are ready and so on and blablabla 

But this is not things that an average user appreciates. The average user is
primarily concerned with features - 

    User: Can it do this, can it do that ?
    Dev:  well yes but it leaves a giant security hole on you computer !
    User: Cool - I always wanted it to do this and that !
    Dev:  errh... yes but it leaves a giant security hole on you computer, and
the mac-users won't be able to do it !
    User: Do you think that we could make it do some other stuff too?
    Dev:  *shrug* yes I think that it is possible

My motivation for working with Moz is a mix-up of microsoft resentment, and the
fact that Moz comes on all platforms (the latter being the most important). Moz
makes my work easier, more creative and more enjoyable. Therefore it is very
important to me that people actually start using it on a massive scale. That
would have a direct and positive impact on my professional live. However people
do not understand 'pipelining' and they don't care. Which is not to say that
pipelining is not important and not cool - it is. In my book however it comes
second to editable elements, because editable elements will have a direct and
positive effect with the userbase, a thing like pipelining has a more subtle
impact and can therefore wait.

I am sure that there is a lot of important issues, and what I am doing here is
trying to put some weight in behind the editable thingy - to make that more
important, because to me and a lot of other web-devs it IS very important.

I really think that it should be done the most easy way - expose the elements as
editable to the scriptable part of the DOM, and let the web-dev community take
care of the rest. Very soon you will have an abundance of editors with toolbars
and all sorts of cool stuff. If you force some sort of toolbar with it you will
only restrain web-devs and their creativity.

Imagine me saying: "Oh your company prefers IE on the intranet? Well we can work
with that, but it puts certain limitations on the project... Have you considered
Mozilla? It's free and it is superiour and it will even work for those of you
who uses Mac " :) ?

>if there is a commercial need for this feature i think we could go and 'sponsor'
a developer to build what is needed (i saw this happening with the roaming

There is a commercial need, and it is currently being met by IE, I am only
representing myself and my one-man-company so I won't be able to sponsor it -

With the advent of 1.0 and Mozilla 1.0 (and KDE and Ximinian
evolution and...) Microsoft will be getting a run for their money. There is not
one thing that an average medium-sized company is doing right now, that they
can't do on a Linux desktop. 

Now what is left is making sure that the advocates gets some ammo - and cool,
eyecatching features is precisely that sort of ammo - hence I'll reiterate:

    "You cannot underestimate 'sex-appeal' in the 
    user-interface when it comes to swaying users"

And I'll boldly continue

    "...and a textarea just isn't very sexy!"

And this feature is not only cool and eyecatching, it's actually valuable!

Priorities is what it is all about, and I am doing what I can to make this
edit-thingy seem more important, because to me it IS  important !

I love Mozilla - and I feel very grateful towards all actively involved in
creating it. I am part of the layer between Mozilla-developers and end-users. I
am one of the guys whose job it will be to sway users - that is why I speak my
mind on this matter, and that is why I think that editable content-areas are
Comment 58 JT Smith 2002-05-13 14:57:38 PDT
>I love Mozilla - and I feel very grateful towards all actively involved in
>creating it. I am part of the layer between Mozilla-developers and end-users. I
>am one of the guys whose job it will be to sway users - that is why I speak my
>mind on this matter, and that is why I think that editable content-areas are

Me too. I feel exactly the same way. And I can add even more weight to this on
two counts: 

1) I'm the Director of Technology at a Fortune 500 company in Chicago (to cover
my butt I won't say which one). Therefore I'm in a position to help mould the
direction toward products like Mozilla. Before I came to this company, almost no
one had even heard the word open source. They are now using Apache, Linux, Perl,
Java, Tomcat, JBoss, MySQL, Net Beans, WebGUI, and many other open source
products. And now I'm making a push for the desktop.

2) I'm the leader of WebGUI (, the open source CMS. There are
many big companies, universities, and schools using WebGUI and for the most part
they'd drop IE in a second if it would mean they could use our Rich Edit
functions in one common browser among every platform they use. Desktop-wise that
includes every flavour of Windows, Mac, Linux, and Solaris you can imagine.

If I had any programmers I could spare at either company you can bet I'd be
sponsoring this myself. As it stands I'll do whatever I can, though I'm not sure
what that is. Except maybe to say what I just said.
Comment 59 saari (gone) 2002-05-13 15:32:08 PDT
FYI, we have internal customers as well for this so it has a high likelyhood of
happening, although not before 1.0 goes final. Perhaps 1.2 depending on how
timing goes and what ends up being implemented/needed first. So please be
specific about what you need and what you want ideally, and thanks to those that
already have said as much.
Comment 60 Michael Stearne 2002-05-13 15:49:21 PDT
What our organization needs at a minimum is shown in the example attachment ( ).  I thought
the target was 1.1 ...

Comment 61 saari (gone) 2002-05-13 16:05:26 PDT
target is as soon as we can get done whatever we need to get done :-) That may
be 1.1, maybe 1.2, won't know for sure until we decide on a course of action
Comment 62 Esben Maaløe 2002-05-13 16:36:01 PDT
What I'd like from an editable content-thingy.

1.  First and foremost I'd like it to be there!
    Silly point perhaps - but I can eat any solution,
    as long as it gives users a familiar word-processing-
    like environment in which to supply content.
2.  I'd like it to set me free - I am a web-developer
    I can judge my users needs when I talk to them. I'd 
    like to be able to respond to those needs, and not the 
    needs of the majority of browserusers in general.
    Any embedment of the composer should give an absolute
    freedom in regards to toolbars etc. Keybindings should
    be the standard, I have no need to introduce CTRL+SHIFT+F12
    when people are used to CTRL+C (or APPLE-C or whatever), but 
    all that has to do with the appearance and layout should be 
3.  I'd like to be able to tell where the caret is, so that I 
    can mangle the text as I please, and put the caret back where
    the user expects it to be (dynamic creation of URLs is a good
    example). Why this isn't in the W3C standard is beyond me. 
4.  The idea of a TEXTAREA with a new propertytype is in a sense OK,
    but not as an only option - I mean if it is somewhat quicker to 
    implement, then perhaps this is where it should start - but I 
    think that the idea of a 'contentEditable' property of div and 
    other block-tags (or any tags at all) is really the way to go. 
    Somewhere inside the belly of the Browsers memory it's all just
    data anyhow, and everything is just a node on a tree - why not
    be able to access it? I mean click on an image and turn it into
    a text - or, at the webdevs discretion, pop-up some imagechoosing
    The argument that the TEXTAREA will let older browsers display it
    as a plain TEXTAREA really isn't that good. If you are doing some
    serverside-programming (you'd have to in order to make the thing work), 
    you can do a quick serverside browsersniff and give people what they need 
    (you'd probably have to anyway - there *are* IE users out there :).

5.  All issues in the direction of 'how will the user know that this is editable'
    and 'how do we deal with linebreaks in a non-block element' is up to the 
    webdevs. They can use this poorly and fail, or they can use it brillantly
    and prevail, it's really not the concern of the people making the browser.
So to sum it up - what I pine for is FREEDOM to develop what I need/want.
A solution that makes a lot of choices for me, is also dictating what I
can offer my customers. I'd like to dictate that myself :) This is also
one of the charms of the whole OSS scene, that freedom where the only restriction
you meet is that of your own limitations. My limitation is that I haven't got
the time nor the skills to just download Moz-source and start hacking it myself.

I'd be happy to participate in a more implementation-centric discussion, but the
headline for my wishlist is FREEDOM!
Comment 63 Jaro v. Flocken 2002-05-13 16:52:04 PDT
I add my votes to Esben's post (esp. to p 1)

A div (with css-p) or textarea would be cool. 
Access over the DOM to the inner content of this node is a must to make fancy
dialog bodex/buttons etc (I think this is already the case in composer)

Moving the caret the the key arrows CTRL+X/V/C DEL BACKSPACE PG UP/DOWN POS1/END

Optional: An event/command for paste/copy from the lokal clipborad would be
great (For the usual toolbar) -- but this can be a security issue.

Comment 64 Sjoerd Visscher 2002-05-14 02:41:51 PDT
Esben: #3 has a W3C standard. Try this:
var range=window.getSelection().getRangeAt(0);
var nodeAfter=range.startContainer.splitText(range.startOffset);
nodeAfter.parentNode.insertBefore(document.createTextNode('hello'), nodeAfter);

range.insertNode(document.createTextNode('hello')) should work too, but it has a
bug (I think)

A lot of things can already be done through javascript. The most important
missing feature is a visible caret. And it would be nice if user input handling
would be taken care of by Mozilla. (Moving the caret one position to the left
when the left key is pressed can be done with javascript, but you don't want to
script those things) These two features should be enabled when the css property
-moz-user-modify is set to read-write, for any element.
Comment 65 Lasse Marøen 2002-05-14 03:33:04 PDT
> The most important
> missing feature is a visible caret.

Have you tried caret browsing mode? Press F7 and you have a visible caret in the
browser window. It enables you to select stuff and move the caret with arrow
keys, but you can't edit anything.
Comment 66 Erik Arvidsson 2002-05-14 05:09:00 PDT
Caret browsing: That's sweet. Shouldn't there be a menu item for this in Edit 
or view?

When was this added? Is there any way to set this using scripting?
Comment 67 Martijn Kluijtmans 2002-05-14 07:58:52 PDT
Look at for editing
text in Mozilla
This is a very basic, but I think a good script to start
Comment 68 Esben Maaløe 2002-05-14 08:43:01 PDT
Sjoerds example combined with caret-browsing is very exciting. It goes to show
that mozilla is actually not far from there. I agree however that scripting
key-events in order to produce content is not optimal 

Funny thing that caret-browsing, it may be buggy though, try it here:

My caret runs around inside the same element and cannot escape (I'm using RC2) -
I am not sure whether to file this as a bug, and I request that some of you go
have a look and decide if it is a bug.

It seems to me that all the functionality needed, already is in Mozilla, and it
only has to be fitted together?
Comment 69 Aaron Leventhal 2002-05-14 09:12:15 PDT
To turn on browse with caret (read only) mode:

prefs->SetBoolPref("accessibility.browsewithcaret", true); // or false to turn
it off

Comment 70 Jesse Ruderman 2002-05-14 14:26:32 PDT
Most of the "caret browsing gets stuck" bugs are actually editor bugs.  The same
bugs appear while typing an e-mail message or editing a page in Composer, and
will appear in <div style="-moz-user-modify: read-write; height: 5em; border:
2px inset #ccc; overflow: auto;"> or <htmlarea>.  If you find "caret browsing
gets stuck" bugs, please file them after searching the Editor components,
because that will make Composer and -moz-user-modify suck less at the same time
it makes caret browsing work better.

By the way, have you tried the "edit page" bookmarklet in IE?
   javascript:void(document.body.contentEditable = 'true')
It has many of the same problems as Mozilla Composer on complex web pages
because it's intended for creating simple content.  Many bugs that show up while
editing forms and tables on don't show up often when you're typing an
e-mail message.  That doesn't mean we should ignore bugs found while editing (they do interfere with caret browsing), but those bugs don't prevent us
making -moz-user-modify work reasonably well.
Comment 71 Kathleen Brade 2002-05-14 14:34:34 PDT
>Most of the "caret browsing gets stuck" bugs are actually editor bugs.

I believe most if not all of these types of bugs are actually in the "selection"
component (not in an editor component).
Comment 72 larhal 2002-05-16 01:27:23 PDT
If simply specifying a contenstype of text/html to a textaria 
eliment brougt up the composer for that textaria it would be 
a killer.

Its easy to use for webdeveloper, its easy to implement in different 
ways in different browsers (ie, call upp an extern app in an browser
only browser).

Browser not suporting it would give the raw HTML to edit so it is 
transparent to older browsers (it shuld require quoted HTML in the 
textaria to maintain that backwards compability).

Thanks /LaH
Comment 73 bugzilla 2002-05-18 15:49:03 PDT
Hey folks,

I've been following this bug with interest for a while now. I have a client who
asked for a way to edit and/or add to pages in house, so recently embarked on
the journey to furnish them with such. I don't like doing platform specific
development, and generally do all my development in Mozilla, but after much
research it seemed that IE was the only browser which had all the functionality
I needed. I've never done any "IE only" development before, so it was an
interesting learning experience.

I've developed an application which basically lets certain parts of a page be
set editable, wraps them in a WYSIWYG editor with standard toolbar buttons to do
the formatting, and publishes the changes back to the server. It works a treat
if I do say so myself. It uses W3 standard DOM wherever possible, and for those
areas where it isn't possible I wrote thin wrappers which do the right thing
depending on which browser is used. All in all, it turned out much better than I
ever anticipated.

The thing that's really great (or really a shame, depending on your viewpoint)
is that it's almost totally cross platform. I did 90% of the development work in
Mozilla (and let me say now that development in Mozilla, while not perfect, is
at least an order of magnitude less painful than doing the same thing in IE);
save for the actual editing of text, everything looks and works exactly the same
in both browsers, including instantiating the editor and publishing changes. All
I'm missing for it to be completely cross platform is the ability to make a
block editable in Mozilla.

I've thought a lot about what form I'd like that to take. I think I agree with a
previous poster that exposing the basic functionality and letting the developer
build the actual editing application is the best way; it has the maximum
flexibility, and it's just not so hard to do that we need the Mozilla team to
present us with a fait accompli. I know there has been a lot of discussion about
simply putting in a tag and having an instance of composer show up, but that
would actually be bad for me. It's much heavier than I need or want, and almost
certainly wouldn't give me the control I need.

What I'd like is to be able to set a div, say, to editable and be able to do
operations on entered text. What that would mean is that I hit a key, the letter
shows up and the caret moves. Behind the scenes, I'd like to be able to either
set formatting on highlighted text (through an API ala IE perhaps) or wrap it in
tags of my choosing and have it rendered it accordingly (I've actually managed
to do this in Moz, but it's a little clunky because of problems with the range
object and it's not worth much if I can only use it with existing text).

As I say, I've gotten everything I described above with the exception of
entering text working, and I have a feeling that if I wanted to write some
really hairy Javascript, I could probably make that happen too; I may just try
it. The whole functionality is so damn close I can taste it, and it's really
frustrating not to be able to carry through. It's especially frustrating because
I have clients who would be willing to buy this from me tomorrow if it worked on
Macs, and it doesn't look like MS intends to expose this functionality there
anytime soon.

I know you want to focus on end users, but I can move a fair number of people
from IE to Moz immediately if you just make this functionality available. Moz
doesn't have to do all the work for me, it just needs to make it possible. I'll
take care of the rest. Before I go, I'd also like to say that I've more than
once stumbled across functionality in Moz that I didn't know was there and had
never seen documented; if something I'm wanting is already available (in any
form, as long as it can be used without hacking C++) please let me know where to
find info on it.
Comment 74 Tony Gorman 2002-05-18 17:18:20 PDT
Can I just echo the sentiments expressed above.

I also have done a fairly complete editor that works in Mozilla. All I need to
polish it and make it better than IE is to be able to insert text at the caret. 

I do not want an embedded Composer - although I could put that to good use as well.

I want to be able to set a DIV on the page as editable, so that my keystrokes
will insert text at the caret or, it can take a selected range of text and wrap
or unwrap tags around it. 

Even if it was possible to calculate where the caret was in a DIV declared as
editable, I could hack some JS to insert my keystrokes.

Incidentally, the mshtml feature of IE is kinda nice. but it has a weakness that
Mozilla could exploit by the aforementioned caret enhancements. That is, the
code the various execCommands() produce is not valid XHTML. So, if you are
trying to produce well formed XHTML, mshtml  is of little use. You have to
resort to using the textRange object in a textArea or in an editable DIV. We
already got a range object in Mozilla, and we already have a getSelection() - we
just need to go that last half step and allow an editable area where selections
and ranges and caret insertion is possible. 

As the previous posts have said, give us that and we will do the rest. Hell, I
will even stick my editor on Mozdev and let everyone finish it and use it.

Comment 75 Laurens van den Oever 2002-05-28 05:51:52 PDT
We needed contentEditable now to build a proof of concept of our Xopus editor 
on Mozilla. So we have made a very crude implementation ourselves.


This implementation is by no means complete nor stable but only meant as a case 
study. We still hope contentEditable will be part of Mozilla 1.1. 

Comments and additions are welcome.
Comment 76 Esben Maaløe 2002-05-28 06:07:50 PDT
Just previewing this brings tears to my eyes - *snort*...

Can't wait to download and play with it

Esben Maaløe
Comment 77 Boris Zbarsky [:bz] (still a bit busy) 2002-05-28 21:43:07 PDT
*** Bug 147575 has been marked as a duplicate of this bug. ***
Comment 78 Jason Taylor 2002-05-30 15:29:14 PDT
Im just gonna agree with all of the above we have a IE only app for editing web 
sites that we would love to make platfrom independent

plz plz plz put this in soon
Comment 79 Tony Gorman 2002-06-04 05:05:02 PDT
The Xopus implementation is very close to my version.

It is obvious that very little really needs to be done to get this working. For
me the following is enough to  allow an explosion on HTML editors to appear:

1). Introduction of a contentEditable Tag 
2). The ability to identify the caret position inside an area where
contentEditable=true, in relation to the area. EG report that the caret is 10
characters along in the string representation of the content.
Comment 80 Alfonso Martinez 2002-06-10 05:37:45 PDT
*** Bug 150609 has been marked as a duplicate of this bug. ***
Comment 81 Jesse Ruderman 2002-06-14 11:00:29 PDT
See also bug 151765, which asks for a way to open Composer using javascript in a
web page (4xp).  I prefer the method in this bug: allowing the page to make a
div editable, and giving the page a way to ask the browser for a hovering
composer toolbar for functions like Copy and Paste that can't be done using
Comment 82 Peter Wilson 2002-06-21 14:54:21 PDT
I have recently implemented a simple XML editor in mozilla using -moz-user-input
styles. This CSS3 approach shows great primise. I have sent a copy of the editor
to Ian Oeschger for him to review. Unfortunately the CSS3 -moz-user-input styles
are only partially completed. Missing are:

1. A caret in input cable areas.
2. Tabbing between input capable areas.
3. A keyboard interface for character insertion/deletion.
I have managed to get around some of these limitations in the prototype.

I have been persuaded to place this project on MozDev with the intent of adding
XML dialect specifiec editors/viewers. E.g. Docbok, XUL SVG, XSL etc.

The editor also currently has a partial implementation of RelaxNG for document

I really need for some progress to be made in resolving the above problems
before any further progress can be made.

Any ides of What and When?
Comment 83 kaldari 2002-07-05 07:57:10 PDT
Would someone like to bump the target milestone?
Comment 84 kaldari 2002-07-05 08:08:43 PDT
Sounds like "Future" to me. No point in having it set to a milestone that's already passed.
Comment 85 Mike Gifford 2002-07-07 12:33:51 PDT
I run a Linux shop.  Do development in PHP/MySQL CMS Tools mostly.  However in
looking for a way to allow users to do basic WYSIWYG I was damn impressed with
what you could to with IE and javascript (that isn't possible in Mozilla).  

Something like this would kick ass:

The ability to specify a textarea which would allow folks to write as they would
in a Word Processor..

Comment 86 jp 2002-07-08 01:53:22 PDT
Wondering the discussion on dhtml, htmlarea, htmledit etc. I agree with Laurens
van den Oever and Peter Wilson, XML is the way forward.
Microsoft uses execCommand in contentEditable areas.
execCommand('command')places tags around or opens a tag depending on the
command. For instance execCommand('Bold') places <STRONG> tags around the
selection or opens the tag for new inserted content and closes the tag when the
command is called again. These commands are browser buildin (Dhtmled.ocx IE5+)
so your stuck with what micro$oft grants you. It would be more usefull if
execCommand can envoke commands based on the DTD used by the document your

Comment 87 Samir Almousawi 2002-07-08 06:30:12 PDT
When is the release date (when Mozilla starts supporting functionality similar 
to IE contentEditable=true property)
Comment 88 saari (gone) 2002-07-08 09:24:00 PDT
there is no release date yet, we're scheduling the work and figuring out what
exactly we'll do in the first go round and who will be doing it
Comment 89 Roland Sippel 2002-08-17 13:10:11 PDT
I also hope for this: 
My Reason: 
At this time it is not possible to use Mozilla for ANY Content Managementsystem
which use a web-based WYSIWYG Editor. ALL CMS i know only support Internet
Explorer for use.
You also can not develop an WYSIWYG Editor for Mozilla with JavaScript or DHTML
because there is no Engine which you use for this.

See my attach at: Bug 163249
Comment 90 Alfonso Martinez 2002-08-17 13:51:53 PDT
*** Bug 163249 has been marked as a duplicate of this bug. ***
Comment 91 Markus Hübner 2002-08-26 02:33:19 PDT
Having the same view as stated in comment #89.
This is highly needed, as leading content-management-system vendors are all 
facing this problem and major companies won't decide for Mozilla if they are 
not possible to use their web based cms systems.

Comment 92 Doron Rosenberg (IBM) 2002-08-26 09:23:54 PDT
Major European companies have asked about such a beast as well, so making topembed
Comment 93 Akkana Peck 2002-08-29 11:02:08 PDT
Add dependency on edembed
Comment 94 Zac Spitzer 2002-08-30 09:28:26 PDT
if this was then wrapped in an activeX control, this could be embedded in IE for
a consistant cross browser toll too
Comment 95 Keyser Sose 2002-09-04 17:36:23 PDT
Looks like someone just put a bounty out on this bug...or its kin...the bounty
includes a monitary sum (bout 1/4 of the way down search for 'I Just
Can't Take Internet Exploder Anymore'

Comment 96 Keyser Sose 2002-09-04 17:37:02 PDT
Looks like someone just put a bounty out on this bug...or its kin...the bounty
includes a monitary sum (bout 1/4 of the way down
search for 'I Just
Can't Take Internet Exploder Anymore'
Comment 97 Charles Manske 2002-09-04 21:26:16 PDT
That's interesting! 
I've made editor embedding topics such as this (tracked by bug 157128) a major 
priority during the next few months (and didn't need any monitary incentive :-)
I studied the MS/IE HTML editor interface carefully today and we will have no
problems supporting this once the editor embedding goals are fulfilled; but if
you design an editor to our interfaces, there will be much better capibility,
of course!
Comment 98 kaldari 2002-09-05 07:48:46 PDT
I would be happy to throw in a case of beer to add to the bounty. I'm so sick of 
recommending that our clients use Explorer if they want to use our web apps. And they 
still don't work on Mac, only under Windoze. Whoever resolves this bug is making 
inroards against two monopolies. They certainly deserve all the support we can offer.
Comment 99 Doron Rosenberg (IBM) 2002-09-05 11:16:54 PDT
so contentEditable doesn't work in IE mac?
Comment 100 Michael Stearne 2002-09-05 11:39:07 PDT
This editor functionality in IE definately does not work on IE Mac.  This is a
real stopper for us because we would like to do a fairly large rollout of MacOS
X. Mozilla/Netscape is preferred, but IE would have been adequate.
Comment 101 Alfonso Martinez 2002-09-07 02:46:13 PDT
*** Bug 166987 has been marked as a duplicate of this bug. ***
Comment 102 Kathleen Brade 2002-09-10 13:16:42 PDT
changing alias per cmanske, akkana, glazman
Comment 103 Hixie (not reading bugmail) 2002-09-10 16:38:37 PDT
The content-decoding issue should not be an issue. You spool the raw stream,
then once you know the target location, you move the file and pass it through
the chain of decoders (and this should all be happening on a non-UI thread of
course). If the decoders are HTTP-specific then that should be changed, since
other protocols may well want to do content decoding.
Comment 104 Hixie (not reading bugmail) 2002-09-10 16:55:45 PDT
er, wrong bug, my bad.
Comment 105 Daniel Glazman (:glazou) 2002-09-11 01:27:18 PDT
Midas, because everything it touches becomes (Netscape) Gold :-)
Comment 106 Alex Vincent [:WeirdAl] 2002-09-12 18:36:07 PDT
Sounds interesting.  1.1 is out the door.
Comment 107 Robert Koberg 2002-09-12 18:54:15 PDT
------- Additional Comment #106 From Alex Vincent 2002-09-12 18:36 -------

Sounds interesting.  1.1 is out the door.

Why? There is nothing about contenteditable in 1.1 or 1.2 or at least nothing I
can see from the release notes.

Is the problem making it work on all platforms? If so, make incremental releases
that work on whatever platform allows. hopefully those that don't (apple...)
will expose things that allow their users to enjoy the same benefits as windows

Comment 108 Scott Blanchard 2002-10-08 08:21:22 PDT
I EARNESTLY and completely vote for this functionality to be added to mozilla 

This would be nirvana for our application - but it MUST work across platforms. 
We currently use IE contenteditable for our CMS to allow users to edit their 
page content. 

I implore you to add contentEditable to Mozilla. It will have a much greater 
impact than any other single thing that you can do and it will pay huge 
dividends in user base and increased downloads of mozilla. I have several 
thousand customers alone who would be encouraged to download Mozilla in order 
to edit the CMS content on Macs.
Comment 109 Charles Manske 2002-10-08 22:25:58 PDT
yes, yes! This is the holy grail of the editor. We are working hard on this!
We need to fulfill basic embedding requirements such as "removing editorshell"
(architexture restructuring) and conversion to command-oriented API, then we'll be 
able to make the jump to "in place editing" or what I like to call it, "editing 
Comment 110 Susie Wyshak 2002-10-09 08:23:57 PDT
added nsbeta 1 kw.
This feature will have numerous benefits leading to increased Mozilla browser
usage and added value for embedded browsers:

1) Webmail sites (AOL, Netscape, Yahoo, etc) can easily offer parity with IE's
functionality, where you can compose messages with a WYSIWYG editor

2) AOL Hometown and other sites that host web pages could include HTML editing
capabilities in their page creation GUI. 

3) Companies that manage their intranets and websites using content management
systems can support Mozilla instead of or in addition to IE. Several
"evangelists" inside top 100 companies are trying to get their IT depts. to
support Mozilla instead of IE or Netscape 4 only. This is another critical
feature that will help them in this effort.

It is important to get more people using Mozilla inside companies so they then
want to use it at home etc. I know I'm preaching to the choir here!

This comment from a content management vendor:

Everyone from Vignette to Broadvision uses IE for their online editing tool
because of "contenteditable". There is nothing else available for this task
short of a java applet. Mozilla's adoption of this feature should naturally be
embraced by this market as well as countless developers all around the World who
expose editing functionality for their clients in this manner. Mozilla would
allow this functionality to be exposed on the macintosh platform which is used
by better than 90% of the design/ad agencies, which would further drive adoption. 
Comment 111 bugzilla 2002-10-09 09:16:09 PDT
*This feature will have numerous benefits leading to increased Mozilla browser

I really wonder if the Mozilla folks know how true that statement is. This
feature has been a long time coming, and I've seen a lot of statements along the
lines of "we're concentrating on features useful to end users instead." Right
now I'm recommending IE to my end users, many of whom prefer Netscape 6.x,
because of the lack of this one thing. Not only is Mozilla not gaining users,
it's actively losing them.

The combination of browser based editing and Mozilla's cross-platform nature is
a killer app, people. There is a huge opportunity here, for both Mozilla and
developers. I've been following this with increasing frustration (I have one
client who's a Mac user who asks me when I'll have something he can use every
few weeks) and I've about given up hope. I wish I could help, but I've tried
several different ways of doing this in Moz (as well as the Bitflux and Xopus
editors), but nothing works nearly well enough to actually be usable by my
clients. I assume it requires hacking in the core Moz code and I'm no
programmer, so I'm useless there (go ahead, I gave you the opening, smack me
down ;).

Give me contentEditable functionality and I can (and will) have my editor ported
in less than a couple of hours. Once that's done I will have recommended IE to
my clients for the last time. I *know* I'm not the only one that's true of. If
you want to see an overnight explosion of new end users, it's right there waiting.
Comment 112 Robert Koberg 2002-10-09 09:38:01 PDT
I hope the mozilla developers are listening to this latest round of requests. It
is really true that this is the thing that could really drive adoption forward.
The request should given much more priority.

We have many designer clients who do not have Windows machines. We keep a couple
of laptops around to loan out to them. One of our designers who is on his 3rd
project with us finally broke down and bought VirtualPC (we have been telling
him Mozilla will have this functionality soon...).

The people who are requesting this feature should not be counted as a single
user (if that is the determing criteria for working on bugs). Rather they should
be counted as 10s or 100s or possibly 1000s of users because they would directly
cause the spread of the browser. When this feature is implemented the browser
will grow much stronger roots.

Is there any kind of a status report from the moz devs on where this feature is?

Comment 113 Michael Stearne 2002-10-09 10:27:53 PDT
Likewise, we have a site that is in use by thousands daily and have a feature
that I am not comfortable really pushing unless it can be offered
cross-platform. I would be behind the feature if I could recommend
Netscape/Mozilla for it.
Comment 114 Charles Manske 2002-10-09 11:32:30 PDT
As one of the main editor engineers working for Netscape, I will again say we 
are working very hard toward this goal. I'm very sorry we don't have andy specs
up, but basically we plan to support the MS/IE interfaces.
I'm talking with our own evangalism people today and also with the DIG group on
this issue. We are making good progress in 1.2 timeframe to have major editor
embedding work done that will enable this to proceed.
Comment 115 Michael Stearne 2002-10-09 13:06:00 PDT
That is great news.  I'm sure there are many like me subscribed to this bug that
over the past couple months have seen many users subscribing to the bug, but
haven't really gotten any update on the fact that developers were actually
working on it.  The last few posts I'm sure will give many of the subscribers a
lot of hope that we will soon see this appearing in nightly builds and releases.
 Thanks again for your efforts developers.
Comment 116 Scott Blanchard 2002-10-09 16:50:57 PDT
Great News Charles!

Just to clarify though, are you saying that the contentEditable attribute is 
scheduled for inclusion in the 1.2 final (October 30, 2002)? Or are you saying 
that you will have made the necessary modifications to the editor that will 
ALLOW contenteditable to be worked on and included in a future release? If the 
latter is the case, what is the projected date that we will see this in 
release? And perhaps when in a nightly build? 

Someone Please alert the list when this appears in a nightly build!!!
Comment 117 Charles Manske 2002-10-09 17:54:07 PDT
"contentEditable" attribute will probably not make it by 1.2, unless we are 
exceedingly lucky. And don't worry! You'll know when anything appears in a 
nightly build.
We need to investigate some security and events/focus issues besides the basic
editor work we are now doing.
We'll post time estimates as soon as we can.
Comment 118 Susie Wyshak 2002-10-09 18:36:12 PDT
Created attachment 102403 [details]
Baseline content editable features list

For all people cc'd who want to use this functionality, you can help in a
couple of ways:

1) Please read this attached file, which contains the potential base set of
features that would be available.

2) Attach a text or HTML file with any additional "must have" and "nice to
have" features that would make content editable acceptable for you. 

Any example URLs that illustrate your requested functionality would be really
helpful. Or you could attach additional screenshots illustrating features
you're using in your systems today...or whatever you think will help.

(Please make sure to use Create an Attachment instead of writing in Comments,
which could very well get lost in this long bug.)

There's no guarantee all requirements will be met but your input will provide
great direction. Thanks.
Comment 119 Rib Rdb 2002-10-09 19:22:34 PDT
I think the features listed in the attachment are heading in the wrong
direction.  By simply allowing javascript access to the selected text or the
word under the insertion point, and the ability to wrap/unwrap any arbitrary tag
around that text, or find out what tags inclose that text, it would be easy to
implement all these features and more in javascript.  Then a simple .js file
could be included to simulate the microsoft functionality for those who want it,
but those who want to do more will (like me) will have the power to do it.  
Comment 120 kaldari 2002-10-09 21:16:50 PDT
I agree that inserting arbitrary text or HTML at the current cursor position or
around the current selection is a must-have feature. But I also think that
providing easy methods for performing the functions mentioned in the previous
attachment isn't a bad idea, especially if it facilitates compatibility with
currently implemented web apps (that use the M$HTML functions).
Comment 121 Christian Stocker 2002-10-09 23:32:56 PDT
We at Bitflux ( don't need all those HTML
Capitibilities, either, but I see certainly use for them for a lot of people.
But what we really would like is to get rid of our
now-written-in-js-character-inserting-with-caret-mode :) It works, but a lot of
people complain, that it's not the "Real Thing". For example, we can't simulate
the common use of the "end" key and going onto the beginning of a line.
Therefore what we (not speaking for others) really need is just good character
editing possibilities (as typing, deleting, moving around and maybe copy/paste)
within dedicated notes. If we then still can use the standard JS/DOM stuff
within that nodes, we're all more than happy and satisfied. And we should be
able to use it on non-html-namespace-nodes, as well, please :)
Just my 2 cents and thanks for your great work.
Comment 122 Robert Koberg 2002-10-09 23:56:44 PDT
Ditto the bitflux guys et al. That is all we are looking for too. We would not
use anything in the list posted a few messages ago.
One thing I like about IE is the ability to click an item and the control
(outerHTML) is selected. When you click again you are inside the element. 

Also, I would want the ability to tab through the nodes.  Example:

<div class="article">
  <div class="section">
    <h2>Sub title</h2>
    <p>Some <strong>para</strong> stuff</p>

I can click on the article div which gets selected - when I hit tab it goes to
the H1, next to the section div, then to the H2, then the p, then the strong.
The tabbing selects the entire node/element. If the enter key is pressed focus
goes inside the selected element. I will get an example up tomorrow sometime.

Comment 123 seb bacon 2002-10-10 01:39:15 PDT
Created attachment 102426 [details]
2 extra wishlist items
Comment 124 seb bacon 2002-10-10 01:47:40 PDT
I agree with the sentiment that it would be better simply to expose a usable API
for caret browsing and so on, because that will better lever the skills of the
wider mozilla community - i.e. javascript coding and UI design.

However, I'd rather have a suboptimal solution that it largely compatible with
IE contenteditable in the next few months, than an optimal solution in a couple
of years.  I don't care if it's written in *machine code*, if we can get it soon :-)

Thanks for the feedback, netscape people.
Comment 125 Roman Ivanov 2002-10-10 02:02:11 PDT
One of the greatest features of MSIE WYSIWYG Editors is a capability of pasting
a richtext from a clipboard -- it is particularly important for cut-n-paste from
MS Word. This is needed for those site administrators, who don't create a text
at  webpage, but transfer texts to the web.

If it is possible (at least, on Win32) to implement such feature, it will be great.
Comment 126 Sybren Stuvel 2002-10-10 03:11:46 PDT
> One of the greatest features of MSIE WYSIWYG Editors is a capability of > pasting richtext from a clipboard  If this get implemented, you must be able to _turn it off_! We have so many problems, where clients paste their text in times new roman, and then a piece of Times text appears on a Verdana site. 
Comment 127 Roman Ivanov 2002-10-10 03:27:54 PDT
>We have so many problems, where clients paste their text in times new roman,
and then a piece of Times text appears on a Verdana site. 

It is so simple to remove any unwanted tags and attributes...

I can tell you about it.

>If this get implemented, you must be able to _turn it off_! 

Yes, you are right.
Comment 128 Scott Blanchard 2002-10-10 08:33:04 PDT
Created attachment 102459 [details]
contentEditable API

I have been working with contentEditable since it was first introduced. My
company produces a commercial CMS that uses this functionality. Here's an
suggested API for Mozilla contentEditable:
Comment 129 José Jeria 2002-10-10 08:34:59 PDT
Why not just implement it the same way as IE?
Comment 130 bugzilla 2002-10-10 08:44:11 PDT
Created attachment 102462 [details]
contentEditable wishlist

Attached are my thoughts on a contentEditable implementation. I do want to
point out that I don't want or need Composer or FrontPage level functionality.
The page layouts and styling will already be set; I just need to be able to
give my clients the ability to change some of the content within the site, and
give them some functionality as far as structural markup goes. They don't need
to decide that a heading is +1 font size in dark red; they just need to be able
to mark it as a heading.

I should also probably point out that one of the reasons I'm so hot to have
this is that I've found that Mozilla is a vastly superior development
environment to IE. I actually do most of my development in Moz, then tweak as
necessary to make it work in IE. Having to tell people they need IE to use the
end result just kills me (I just had a client yesterday tell me she'd use IE if
it was absolutely necessary, but she'd really rather find another way).

Cross platform in-browser editing is my current holy grail, and you guys are so
close. I really do believe making this available will make Mozilla *the*
browser to use for content management, and given that there is no question in
my mind that this is where the Web is headed, well... hopefully it'll come

Thanks folks.
Comment 131 Erik Arvidsson 2002-10-10 11:48:19 PDT
Created attachment 102484 [details]
contentEditable wishlist by Erik Arviddson

Here is my list of wishes
Comment 132 Erik Arvidsson 2002-10-10 11:48:34 PDT
Created attachment 102485 [details]
contentEditable wishlist by Erik Arvidsson

Here is my list of wishes
Comment 133 Garth Dahlstrom 2002-10-10 14:33:47 PDT
Created attachment 102509 [details]
GED's Wishlist for Moz Editable content

also has some ideas of how one might implement editable content... 
IE emulation through Javascript, etc...
Comment 134 Mike Gratton 2002-10-10 20:35:18 PDT
Created attachment 102540 [details]
Requirements for in-browser, user-editable DOM nodes.

A summary from attached the document:

An emulation of content-editable is *not* required, just the building blocks to
allow developers to make something similar. A proper implementation of
something like the (now-defunct) CSS3 UI WD withe the above features would be
Comment 135 Rib Rdb 2002-10-10 21:24:21 PDT
Comment #130 and it's attachment say exactly what I was trying to say, but much 
clearer.  I really think this would be the way to go.  And as someone already 
said, you could implement IE's functionality in javascript and automatically 
load that script when a page designed for IE is viewed.
Comment 136 tony collen 2002-10-10 22:52:08 PDT
I will be seemingly one of the few voices *against* this proposed "feature",
mostly because suddenly adding contenteditable attributes will not allow pages
to validate  as valid HTML.  

In addition, while we're adding contenteditable, can we please get <blink> back,
and maybe <marquee> since IE has that, too?  

All that I ask is that everyone stop for a second, and think of the standards,
and the possible repercussions of another browser war.
Comment 137 Adam Hauner 2002-10-10 22:55:40 PDT
> I will be seemingly one of the few voices *against* this proposed "feature",
> mostly because suddenly adding contenteditable attributes will not allow pages
> to validate as valid HTML.

You can add this attributes dynamically via JS for contenteditable user-agents, no? 
Comment 138 tony collen 2002-10-10 23:05:57 PDT
> I will be seemingly one of the few voices *against* this proposed "feature",
> mostly because suddenly adding contenteditable attributes will not allow 
> pages to validate as valid HTML.  

Alright, I take that back, my main reason for being opposed to this idea is
because of the factor of playing "catch-up" with IE. Please don't do it. Stick
to the W3C specs, and only the W3C specs. Otherwise, In 8 years, we'll be stuck
rewriting another browser from scratch.

Don't get me wrong, I *like* this idea of being able to edit a page's contents
directly in the browser, and I've played with XOpus and have been very impressed
with what it can do.  

However, I can't agree with a browser (or the group of people who are
responsible for it) that adds a feature for rendering or interacting with a web
page that is not in the W3C's specs, or tries to compete with another browser.

Say no to war on IE.
Comment 139 Dylan Schiemann 2002-10-11 00:43:27 PDT
I don't see how the goal of this RFE, allow page to make arbitrary elements
user-editable in browser, violates html validity or a spec.  IE's use of a
contentEditable attribute does this, but there is no reason that mozilla can't
expose a simple editing API that doesn't violate existing specifications.

mozilla's mission is not to only implement things that are standardized.  There
is no standard for how to create an e-mail compose box (as far as I know at
least :) ), yet mozilla still implements one.  Likewise, there is no standard
for how an html (or xml) editor should work.  There is a standard for its
output, so provided that the result of using mozilla's implementation for this
RFE is valid html/xml, this should be a non-issue.
Comment 140 Sjoerd Visscher 2002-10-11 01:35:15 PDT
> I will be seemingly one of the few voices *against* this proposed "feature",
> mostly because suddenly adding contenteditable attributes will not allow 
> pages to validate as valid HTML.  

Actually this is a valid concern and Mozilla should indeed not implement a 
contentEditable attribute. A CSS property is a much cleaner approach, and more 
useful. If you still want the attribute then you can do that with one line of 
Comment 141 Robert Koberg 2002-10-11 04:47:50 PDT
------- Additional Comments From  2002-10-11 01:35
>> I will be seemingly one of the few voices *against* this proposed "feature",
>> mostly because suddenly adding contenteditable attributes will not allow 
>> pages to validate as valid HTML.  

>Actually this is a valid concern and Mozilla should indeed not implement a 
>contentEditable attribute. A CSS property is a much cleaner approach, and more 
>useful. If you still want the attribute then you can do that with one line of 

A little less than a year ago I asked both the W3c CSS and HTML lists about
this. The CSS list powers that be said it was an HTML concern. The HTML list
powers said it was an UA's problem - it should not be part of the spec. Here is
a post I found in a quick search:

As to those who do not know how to use this without creating invalid markup, I
say you don't know how to use it. You can assign these items on page load or at
other events. There is no need to write your HTML markup invalidly.

Comment 142 Erik Arvidsson 2002-10-11 05:09:40 PDT
I don't think the question here is creating valid XHTML documents and it is not
a question of being backwards compatible.

The goal is to provide the functionality to get away from a static document to a
document (or part of a document) that can edited by the user directly inside the
browser. (Universal Canvas?)

The goal is not extend HTML. The goal is to allow developers to create
applications that allows editing.

I agree that the idea to use an contentEditable attribute is a bit stupid. It
was most likely done that way because it allowd MS a simple implemenation. MS
has a history of using attributes when CSS is more suitable.

The way to go in Mozilla is of course to use a CSS property. How about
-moz-user-modify or is that only for inputs? This also fits well with how IE is
doing it with contentEditable wich uses the inherit value by default which
follows the CSS semantic for the same value.

Just like -moz-binding is ignored by non Mozilla browsers, -moz-user-modify is
ignored as well. Going this way will allow any XML document to validate and it
will also make all old browsers being able to display the significant information.
Comment 143 Daniel Glazman (:glazou) 2002-10-11 05:21:31 PDT
> All that I ask is that everyone stop for a second, and think of the standards,
> and the possible repercussions of another browser war.

Standards are not standards until they are standardized. That's true for
everything in our world. Everything. And standards can becom extinct and
replaced by another one. And standards can change, Eric Meyer saying that
in that case, they are not standards any more until they are standardized again.

There is no current standard for making an element editable. And there is
no standards body currently working on this. It implies that in the meantime,
all vendors are going to find the best implementation they can have, and the day
they have it, they'll ask for a standards body to be the battlefield.

Being committed to standards does not mean not being pragmatic.

Daniel, Netscape's rep at CSS WG
Comment 144 Zac Spitzer 2002-10-11 05:30:06 PDT
as there is no w3c standard for this and a very wide spread existing
implementation, just do it simple.. as mentioned before, implement contenteditable

forget all the xhtml/xml blah stuff for the first cut... we just want something
simple which works...

honestly, if the xopus code was reliable it would be enough...

the direction of all the editor rework is cool, but that is not IMHO what this
bug is about... its about simple basic editing of text

KISS principle...
Comment 145 michael 2002-10-11 05:43:07 PDT
But what does it mean to "just implement contentEditable"? Because surely this
attribute does not have a well-defined semantics: all we can do is say how it
works on any specific version of Internet Explorer - but Microsoft may well add
arbitrary new functionality in future releases.
Comment 146 Robert Koberg 2002-10-11 05:58:22 PDT
>------- Additional Comments From  2002-10-11 05:43 -------
>But what does it mean to "just implement contentEditable"? Because surely this
>attribute does not have a well-defined semantics: all we can do is say how it
>works on any specific version of Internet Explorer - but Microsoft may well add
>arbitrary new functionality in future releases.

So what? The basic functionality needed is to be able to select nodes or partial
nodes and affect them with JS. Most of the stuff you should be handling yourself
(especially if you are trying to validate the content).

Aside: Since contentEditable did not exist before MS created it, then they
defined it. It is defined.

Comment 147 bora123 2002-10-11 06:39:30 PDT
> Being committed to standards does not mean not being pragmatic.

YES! that is it. Mozilla is being caged into standards which are already 
subsets of another browser ruling the planet. What are thet chances that 
mozilla will be adapted widely in its present form?-> uhm almost 2% jump to 5% 
perhaps. By the way, is Microsoft sleeping at the moment? NO! they will come up 
with even more unignorable features pushing Mozilla back to its oblivious 
stage. By the way, who is more active in w3c anyways? MS?
Comment 148 tony collen 2002-10-11 14:21:36 PDT
Alright, I understand that it's possible to mark up a page that will validate
and still use the attribute.  Now convince me that this won't spark another
browser war.  Why should Mozilla care what IE does?  By implementing nonstandard
things that IE does, the developers are admitting that IE is better, and they
want Mozilla to be more like IE.  Am I way off base here?
Comment 149 kaldari 2002-10-11 14:40:06 PDT
This discussion is destined to degenerate into a flame war. I suggest moving
non-development related comments to the newsgroups. This bug is already spammed
enough as it is (not that I haven't contributed to this myself).
Comment 150 Tim Powell 2002-10-11 14:59:20 PDT
Tony, see comment 10 and comment 114. The plan is to implement the IE interface 
and for good reason: Microsoft IE 5-6 have more than 90% of the browser market 
(That's being generous to non-Microsoft browsers). Microsoft extensions such as 
contenteditable are de facto standards. This isn't the first time (see the some 
of the DHTML properties) and doubt it will be the last time that Mozilla 
implements a Microsoft extension. If Mozilla wants to even be a viable 
alternative, it needs to support a number of Microsoft features. Otherwise the 
switching cost is too great, both for web site developers to support Mozilla 
and for users to use Mozilla (or derivatives).

Also see comment 108, comment 110, and comment 111, and comment 113. I see this 
as pragmatic: the more that is in common between the major browsers, the better 
for everyone.
Comment 151 Derek Petersen 2002-10-11 16:28:04 PDT
"Alright, I understand that it's possible to mark up a page that will validate
and still use the attribute.  Now convince me that this won't spark another
browser war.  Why should Mozilla care what IE does?  By implementing nonstandard
things that IE does, the developers are admitting that IE is better, and they
want Mozilla to be more like IE.  Am I way off base here?"

My god, get off the ego trip. I say we just be compatible with IE so that
Mozilla will be compatible with more websites and maybe we'll get more then 0.8%
of the market some day.
Comment 152 Hamish Allan 2002-10-14 02:25:15 PDT
"Why should Mozilla care what IE does?  By implementing nonstandard
things that IE does, the developers are admitting that IE is better, and they
want Mozilla to be more like IE.  Am I way off base here?"

Surely it can't have escaped your notice that this bug's raison d'etre is that 
IE *is* better than Mozilla with respect to editable content. It may be that 
Mozilla can implement editable content in a more coherent way than through the 
contentEditable attribute, but the more market share Mozilla loses through not 
providing editable content in *whatever* form, the more unlikely it is that 
Mozilla will be able to influence *any* future direction of browser standards.
Comment 153 tony collen 2002-10-16 12:17:03 PDT
Alright, I still think it's a bad idea, but in the interest of letting people
get to work, I'll drop the argument.

Best of luck,
Comment 154 Thomas R. Trenka, Ph.D. 2002-10-18 15:45:31 PDT
Coming very late into the game with this thread...I would have to argue:  
contentEditable would be fantastic; duplicating MS functionality using 
execCommand et al would be horrendous.  I've just finished a 2 month long 
battle with creating a CMS WYSIWYG editor, and the workarounds I had to 
perform simply because of the MS model force me to drink...

I do not know about anyone else who has created / talked about the foundation 
of a CMS, but there is one thing that client have ALWAYS wanted:  the ability 
to limit the user of the CMS to a very particular style sheet.  The MS control 
does not allow you to do this without nasty workarounds (which i have done), 
but it would be SO much better if there were a way to insert / alter / edit 
the entire node properties through assignment.  Perhaps something like 
document.execCommand, but instead of "guessing" which parameters are 
available, the method could perhaps be passed an object (perhaps even a Node), 
which would serve as the template for the execCommand.

This to me (aside from the Range object) would be the most important thing in 
a WYSIWYG editor model.
Comment 155 Bastiaan van Dreunen 2002-10-20 16:43:15 PDT
I would like to draw back attention to comment #119. Rib Rdb I think has a good 
point with what he says there. What he describes would be just enough to create 
a range of functionalities. And it would be 'clean' as well (right?), as 
opposed to the m$ contenteditable ****.
Comment 156 Alfonso Martinez 2002-10-28 14:16:38 PST
*** Bug 177128 has been marked as a duplicate of this bug. ***
Comment 157 Jesse Ruderman 2002-11-05 00:58:49 PST
Created attachment 105172 [details]
some security implications of scriptable copy/paste

Mozilla should omit clipboard commands from whatever API it gives to web pages
for wysiwyg editing.  Since Mozilla doesn't give users cut/copy/paste buttons
on the toolbar whenever they focus non-wysiwyg text fields, I don't think this
should be a problem.
Comment 158 Mike Gratton 2002-11-05 02:16:20 PST
jruderman: I agree with you that the clipboard should not be scriptable, but
note that text areas and other input-fields are clipboard enabled. For example,
you can paste into a text area via the content menu, the Edit menu, or via the
platform-specific keyboard accelerator.

In the same way, I'd be looking to have the clipboard functions automagically
enabled for any elements/nodes marked as user-editable, and disabled when not

Text editing without copy and paste is pretty sucky.
Comment 159 Torgeir Veimo 2002-11-05 02:18:57 PST
It would be nice to be able to script as a result of copy/paste, not necessarily
to initiate copy/paste. A related example is dragging of images into an area
from an image repository in a separate frame.
Comment 160 Scott Blanchard 2002-11-06 20:56:22 PST
I will take whatever the engineers are able to give us as quickly as they can. 
I am hearing this will be in the next release of moz.

However, it would be shortsighted to abandon the ability to paste to/from 
clipboard from an editable area. This is something that users consider 
fundamental to any input area.

Rich text paste would be useful.
Comment 161 Jon Hall 2002-11-10 17:13:50 PST
Did this make the target milestone of 1.2beta?
Comment 162 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-11-12 16:36:37 PST
Hey, you should all download the latest Mozilla build (1.3alpha --- sorry, this
did not make 1.2) and try this:
Comment 163 Erik Arvidsson 2002-11-14 13:04:03 PST
Nice work. This is definately a good start.

I guess you already know that Mozilla raises an exception if this is tried twice
in the same session.

Should we start filing bugs for this or wait until more is in place?
Comment 164 Kathleen Brade 2002-11-14 14:08:36 PST
Erik Arvidsson--
>I guess you already know that Mozilla raises an exception if this is tried
>twice in the same session.
Are you trying to create to editable iframes or do you mean if you reload?
There is a bug filed about the 'reload' problem which is a regression (Monday's
build works for that; possibly Tuesday's build too?).

>Should we start filing bugs for this or wait until more is in place?
Depends what it is.  If it's a security exploit, file the bug and be sure I'm
cc'd (  If it's a missing command, there is another bug
filed on it (look in my bug list) so add a comment to that bug.

At this point I have no plans to implement the selection api IE has since IE's
own implementation is buggy/inconsistent and the document api seems to be
Comment 165 Susie Wyshak 2002-11-19 07:34:26 PST
*** Bug 151967 has been marked as a duplicate of this bug. ***
Comment 166 conor play 2002-11-26 01:20:42 PST
I've been playing around with javascript to make an inline html editor, one that
would drive off style sheets and write "proper" XHTML. It's not trying to be IE.
I think Mozilla opens up a lot more possibilities. The result so far is at: 

The basic selection handling is there. Deletion was the biggest pain due in part
to what I think is a browser bug but it's largely there now but for debugging.
Styles et al should come before christmas.   
Comment 167 bugzilla 2002-12-05 09:16:29 PST
Hey folks,

I just got the chance to check this out a little, and it looks as if it only
works in an iframe? Is that so, and if so, is it going to stay that way? That
would make it next to useless for the way I use this functionality; I really
need a way to make a fragment of the currently loaded document editable.

Is a contentEditable attribute coming, or is setting an entire document to
designMode all there going to be (my apologies if these questions are already
answered somewhere; I've searched, but not found anything outside the midas spec
Comment 168 Kathleen Brade 2002-12-05 10:55:09 PST (comment 167)--

You are correct that right now the rich editing is only available on an iframe's
document.  When that work is completed, someone may be able to undertake the
content editable aspects which will be much trickier.

Will it stay this way?  Hard to say for sure.  If someone steps up and writes
the code and tests it, it can go in.  If not, then it won't.  Personally, I
won't be able to undertake this task for the foreseeable future (next 3 months).
 Are you sure you can't use iframes which contain the data you want to edit?

> setting an entire document to designMode all there going to be
Setting designMode in mozilla is done on an iframe's document (not the parent
Comment 169 bugzilla 2002-12-05 11:47:44 PST
Thanks for the info.

>  Are you sure you can't use iframes which contain the data you want to edit?

Well, I was hoping to duplicate the operation of my editor for IE, which depends
on the ability to set certain (and arbitrary) blocks of a page editable in place.

I might be able to fake it with iframes, but not easily and not without writing
a completely different implementation, which I was hoping to avoid. I'll spend
some time looking into it.

> Setting designMode in mozilla is done on an iframe's document (not the parent
> document).

Yes, I understand that; sorry if I wasn't clear. Again, though, for me to be
able to avoid maintaining two totally separate code bases (which I'm not sure I
have the time for) I'd need to be able to have only certain parts of that loaded
document be editable, or be able to load fragments of an existing document as
the iframe's doc. Doable, but not easily with my current backend, and given that
IE works now I just don't know that I can justify the time and effort. I'd love
to have something cross platform, but all my current clients have Windows
available or can delegate to someone who does, so...

In any case, thanks for the prompt answer; I do appreciate it.
Comment 170 Kathleen Brade 2002-12-05 12:46:58 PST (comment 169)--
>  ...duplicate the operation of my editor for IE...
You might want to look at the samples at these locations (which I'm told work in
both IE and mozilla):

The above don't use contenteditable but do use designMode and iframes.  It may
not work for you in your situation if you have a complex process which involves
multiple editors etc.
Comment 171 bugzilla 2002-12-05 15:01:04 PST
> You might want to look at the samples at these locations (which I'm told work in
> both IE and mozilla):

I'd already seen both of those, but thanks. My problem isn't that iframes don't
work in IE; it's that I tried and abandoned that approach a long time ago, and
my current setup isn't really compatible with doing it that way.

In essence, making an editable iframe is doing things the old way, only instead
of having just a form on a page to enter plain text into you have something that
can create html. An improvement, but the other features of modern browsers make
so much more possible, and I'm loathe to go back to that way of doing things. It
may be fine for something like a blog or posting to a message board, but get
beyond that and things start to get clunky.

I've played with the iframe stuff a little, and unfortunately it's not going to
work for me. I may do something with it in the future so those who can't or
won't use IE on Windows have *something* to work with, but as it won't be nearly
as seamless or as usable as what I already have I fear my best bet is to keep
recommending that my clients use IE. Disappointing, that.
Comment 172 conor play 2002-12-05 16:00:51 PST
so do you want inline editing, of HTML as HTML? Say user-modify=read-write for a
section, say any id'ed section, let's you type away in that section. That's what
I want. 

As I said in a previous comment (#166), I'm playing with javascript to allow
inline editing like that. It's basic now but it should support styles and spans
by christmas and there's a focus bug in the browser that can kick in after
deletion. I don't think you need any custom widget per se, just something to
push the DOM around as you click away. 
Comment 173 bugzilla 2002-12-05 16:21:39 PST
conor play:

Yes, I took a look at what you have and that's very much along the lines of what
I need. I had tried to do something like this in Moz some time ago, but various
bugs in the range object prevented it from working well enough to be usable.

What you've got done so far is too basic for my uses, but where you plan to go
with it sounds good. Given that it doesn't look like Moz is going to get a
contentEditable attribute, I'll take another look. I dislike having to deal with
all the keystroke handling manually (and using caret browsing *really* feels
like a nasty kluge), but if that's the way it is then that's the way it is.

If this looks like it'll eventually work for me and I can budget some time, I'd
be happy to contribute to the effort if you'd like. In any case I'll take a
closer look at it within the next few days.
Comment 174 Laurens van den Oever 2002-12-10 04:05:45 PST
We have today released a new sub-release of Xopus: contentEditable for
Mozilla. Please look it up at

Mozilla 1.3 supports editing of pages, but only by entering designmode
for a complete page. This obviously isn't how you and me would want it, but 
still it's a start.

Our unsurpassed moz2ie.js library has now been extended to tweek this
designmode behavior and make it look like true contenteditable the way
Bill intended it to be.

You can make almost any HTML element editable using one of two ways:
1.  <div contenteditable="true">you can edit this!</div>
2.  <div id="test">you can edit this</div>
    <script language="javascript">
      document.getElementById('test').contentEditable = true;

We hope this will help developers build richer Mozilla based internet

Our implementation isn't complete yet, of course. Please feel free to enhance 
the code.
Comment 175 conor play 2002-12-22 11:35:24 PST
here's another iteration of inline editing using a tweeked DOM: Use either -moz-user-modify CSS or
ContentEditable and include one file, wrap.js, in any page you want to make
editable. This works in the currently released browsers - it doesn't rely on
"DesignMode". Of course, it needs a lot of work still and a good reliability
pass is in order.

My two pence worth on inline editing in Mozilla is:
- with some fixes, the core Mozilla DOM can easily and cleanly support editing.
Mainly this amounts to a few extensions and fixes to Range.
- cross browser compatibility should mean nothing more than supporting IE's
proprietary contentEditable attribute. It does not necessitate emulation of
every IE DOM routine and attribute. ContentEditable should be supported but
support should mean letting end users set this property to activate and
deactivate native DOM editing appropriately.
- fragmenting the code base by maintaining a proprietary "editor" DOM is a waste
of resources and of the core DOM's potential. It will probably mean never
pulling ahead of IE, at least in the area of editing. With all the work in XML,
XHTML and CSS, there is a ton of room to leap frog current IE-based editing. It
seems a shame to just "me too" old IE features rather than supporting more
through fixes and small extensions to the core DOM.

Happy holidays!
Comment 176 bora123 2002-12-22 15:20:15 PST
Why the cursor is visible on the entire content? Isnt it suppose to show up if
the  purpose is editing only? It is good to have contentEditable feature for
Mozilla ,but Users should not get the feeling that they are on editmode for all
the web pages they browse. Is there a way to turn it off or it is there to
stay(hope not).
Comment 177 bora123 2002-12-23 06:50:20 PST
Never mind, it is fixed on today's build.
Comment 178 Brant Gurganus 2002-12-31 23:27:35 PST
If I understand this bug correctly, then it would make Mozilla meet one of
TimBL's visions for a browser.  It could also edit.  See which
is a browser/editor that works in this way. 
Comment 179 Matt Walton 2003-01-14 04:17:58 PST
(added myself to the CC list)
I'm very interested in this, but only really if it can give proper XHTML editing
as a minimum, and free XML editing (with CSS formatting of XML elements) in the
best case. The former would allow me to use XSLT to get the output into the
correct format without doing any messy HTML->XHTML conversions first, which
would be great, and the latter would just be fantastic. Still, the progress made
so far is good.
Comment 180 jp 2003-01-31 01:43:22 PST
Yes I agree with that it should generate proper XML compliant code. This allows
us to do:

Editor => XML

or even:


And all without the need of cleaning up HTML code inserted via the editor.
This prevents us from the garbage in garbage out routines ;-)

Microsoft's contentEditable also has some "support" for this:
When you copy/paste data form Word 2000 into a contenteditable div is shows up
as xhtml-ish code...

Keep up the good stuff
Comment 181 Martin van Dijken 2003-01-31 01:56:30 PST
Oh Please JP,

You're right Microsoft insert word data as xhtml ****, in the meaning that it
has a XML-valid markup. It does however include all kinds of proprietary garbage
tags and a lot of Markup that is very inefficient. I sure hope the Mozilla crew
will make something that produces valid XML, and it would be very nice to get
CLEAN XHTML, but I'm not throwing away my garbage cleanup routines just yet.
Sorry for the sarcasm, but I think it VERY hard to produce clean HTML,
considering my cleanup routines(and others I've seen) aren't altogether perfect
yet either.
Comment 182 jp 2003-01-31 05:46:40 PST
I know, I know. My clean up regexz are starting looking like the Himalayas to
straiten Micro$oft pastes... 
Comment 183 R.K.Aa. 2003-02-03 21:48:35 PST
*** Bug 191833 has been marked as a duplicate of this bug. ***
Comment 184 Kathleen Brade 2003-02-07 10:02:20 PST
minusing request for 1.3; there isn't even a patch to land here!

Some of you watching this bug may be interested in trying this in a recent 1.3
also see:

Any issues found should be filed as new bugs (assuming they aren't already
filed).  Updates to the above documentation are welcome too!
Comment 185 Scott Blanchard 2003-02-13 11:16:48 PST
Thanks for the very nice example. There are some errors being reported in IE6
(Windows XP pro) regarding the InitToolbarButtons(); functions as well as when
trying to view source. Anyone else see this?

Overall though, a very nice example and glad to see this finally available. If
anyone has any more examples and contributions, please post them - this is very
exciting stuff!!!

I am curious if anyone besides myself is in the process of creating a flash
based toolbar for the editor? I think this would be perfect since you could
execute the function calls using the getURL() syntax from flash and it would
atleast insure that your toolbar would look exactly the same in IE as in Moz.
Comment 186 David Mårtensson 2003-02-14 00:10:22 PST
I found that IE 6.0 has a problem with addEventListner.

I used thist construct which works for me.

  if(!document.addEventListener) { 
	document.onmousedown = dismisscolorpalette;
	document.getElementById("edit").contentWindow.document.onmousedown =
	document.onkeypress = dismisscolorpalette;
	document.getElementById("edit").contentWindow.document.onkeypress =
  } else {
	document.addEventListener("mousedown", dismisscolorpalette, true);
	document.getElementById("edit").contentWindow.document.addEventListener("mousedown", dismisscolorpalette, true);
	document.addEventListener("keypress", dismisscolorpalette, true);
	document.getElementById("edit").contentWindow.document.addEventListener("keypress", dismisscolorpalette, true);
Comment 187 kaldari 2003-02-14 12:24:39 PST
In order to prevent this bug from getting more spammed than it already is, I've
set up a Midas listserv to facilitate discussion among web application
developers regarding Midas implementation and troubleshooting. I will send you
all an invite shortly.
Comment 188 kaldari 2003-02-14 13:15:17 PST
Sorry if I invited some of you twice, I was having trouble mass inviting
everyone at once. Anyway, here's the info regarding the mailing list...

You can subscribe or unsubscribe to the list here:

If you are a member, you can post by emailing
Comment 189 John Morrison 2003-02-14 14:23:05 PST
re: comment 186, IE does not implement addEventListener. If memory serves me
the equivalent call is |window.attachEvent("onload", myHandler);| (for the case 
ofsetting an onload handler). Note there is no 'capturing' parameter, and the 
event identifier includes "on".
Comment 190 conor play 2003-03-26 01:02:51 PST
I don't know if this bug is still "active" given Midas' release but to the
interested I've added to the pure DOM-based implementation of ContentEditable
that I'd posted here around Christmas (comment #175). My main goal is an
XHTML/XML editing module that builds on the w3c DOM - among other things, such a
module provides for a straightforward implementation of standards-conformant
ContentEditable. Demos and scripts and more information at
Comment 191 conor play 2003-04-22 18:15:35 PDT
for those interested specifically in "contentEditable" as opposed to
"designMode", the contentEditable/mozUserModify implementation I posted about
before is now a mozdev project called "mozile" for Moz(ila) i(n)l(ine) e(ditor):
Comment 192 Samir Gehani 2003-05-20 09:45:55 PDT
adt: nsbeta1-
Comment 193 Alfonso Martinez 2003-06-16 09:31:12 PDT
*** Bug 209553 has been marked as a duplicate of this bug. ***
Comment 194 Matias Larsson 2004-01-26 06:55:47 PST
OK, I'm now running 1.6b and this was targetted for 1.3b. What is happening with contentEditable? 
Yes, we have Mozile, but I would much rather have it in Mozilla (and Safari, but that's another 
Comment 195 bugzilla86 2004-03-17 17:00:07 PST
(In reply to comment #194)
> OK, I'm now running 1.6b and this was targetted for 1.3b. What is happening
with contentEditable?

It appears to be dead. Nobody in the Mozilla organization appears to have a clue
as to why it would be useful, nor do they appear to be willing to get one from
those who are more informed.

> Yes, we have Mozile, but I would much rather have it in Mozilla (and Safari,
but that's another 
> case).

You may get your wish wrt Safari. Dave Hyatt has said that contentEditable is
near the top of his list of things to implement, and I read within the last
couple of weeks (can't remember where or I'd give a link) that Safari will be
getting cE in the not too distant future.

IE and Safari users will therefore be moving ahead with the functionality that
users are demanding while Mozilla argues about important stuff like who gets to
use what icon...
Comment 196 Matias Larsson 2004-03-18 01:30:15 PST
This is great news! Finally we will have a browser on OS X that will support contentEditable. I actually 
did think that Mozilla would get there *much* faster than Safari, but how wrong I was! Time to degrade 
features for Mozilla or drop Mozilla completely from our CMS-product then.

Quite sad actually... that it takes >2.5 years to implement a heavily requested feature (it's not magic) in 
Comment 197 Jan Frederik Solem 2004-03-18 01:33:13 PST
Has this perhaps been silently solved - at least for some people's needs - while
we weren't looking?:-) Mihai Bazon's HTMLArea (currently at version 3.0 RC 1)
works with both IE 5.5+ and Mozilla 1.3+ - apparently using the "MIDAS"
component in the latter case. Works with Firefox as well as Mozilla. See: 
Comment 198 Matias Larsson 2004-03-18 02:19:56 PST
HTMLArea - A replacement for TEXTAREA elements.

You are right, it will work for some people, but not for those wanting to, for exemple, edit certain parts 
of a web page, but not others.
Comment 199 Soren Vejrum 2004-03-18 02:35:11 PST
The Midas component in Mozilla 1.3+ and Firefox 0.6.1+ implements "designMode",
which is very similar to MSIE's "contentEditable". It works great for editing
content in web content management systems etc. and it is quite easy to make a
simple web content editor with basic functionality. (However, cross-browser
support and more advanced functionality requires a lot of additional
Javascipt/DOM programming to handle differences and limitations).

We have supported it in our own cross-platform web content editor product
( ever since Mozilla 1.3, and we would
love to hear from you if it does not work with your version of Mozilla 1.3+ /
Firefox 0.7+ (on Macintosh, Linux or Windows).
Comment 200 martin 2004-03-18 02:36:42 PST
If HTMLArea doesn't meet your needs, see the Bitflux editor
Comment 201 Brendan Eich [:brendan] 2004-03-18 13:32:34 PST
Insults about cluelessness from people who spam bugs with advocacy comments are
a good reason to revoke bugzilla access from those clueless people.

Clueless Safari fans can cling to every word from the mouth of hyatt if they
want to, but let's get real and talk again (and not in the bug system) only
after Safari actually ships a working content-editable support.

This bug is being degraded by childish noise that does not help get it fixed. 
Since I still (in spite of being insulted by the likes of comment 195's author)
value content-editable, but have no time to implement it myself, I am actively
looking for volunteers who can do the hacking to make it work in Mozilla.

However, most of the talented hackers I know dislike bugspam intensely, so I'm
inclined to close this bug, open another one, and revoke bugzilla access from
anyone who spams that bug.  How's that for vending a clue, hmm?

Comment 202 Stefano Mazzocchi 2004-03-18 13:52:47 PST
(In reply to comment #201)

> This bug is being degraded by childish noise that does not help get it fixed. 
> Since I still (in spite of being insulted by the likes of comment 195's author)
> value content-editable, but have no time to implement it myself, I am actively
> looking for volunteers who can do the hacking to make it work in Mozilla.


I think it would be useful for people like me that would like to help in having
this feature in place but have no strong knowledge of the mozilla internals to
have a few pointers on how this should be done.

I mean, mozilla is a relatively complex piece of software and content-editable
is not something you get from a side (like an few XUL and javascript files), but
a rather intrusive feature that will probably have to deal with a lot of the
mozilla internals.

Personally, I'm scared by the complexity of this task. But it would be
*extremely* helpful to have an insider view of the problem and guide people
inside the jungle so that they don't have to explore it themselves.

I think this is the reason why this bug hasn't been fixed yet: those who know
how to implement it are busy doing more important things and those who really
want this feature are normally javascript programmers and have no clue on how to
deal with the mozilla internals or are scared by the complexity of the task.

All we need is a little bridge across these two islands so that we can walk to
your side and help.
Comment 203 Daniel Glazman (:glazou) 2004-03-18 14:05:18 PST
(In reply to comment #202)

> Personally, I'm scared by the complexity of this task. But it would be
> *extremely* helpful to have an insider view of the problem and guide people
> inside the jungle so that they don't have to explore it themselves.

I agree. I think I know how to implement contentEditable in Mozilla.
But the current bug went totally out of control, from a comments point of view.
I am just fed up with reading noise, and seeing the useful comments in this bug
drown in an ocean of spam.

> I think this is the reason why this bug hasn't been fixed yet: those who know
> how to implement it are busy doing more important things and those who really
> want this feature are normally javascript programmers and have no clue on how to
> deal with the mozilla internals or are scared by the complexity of the task.

This is the case for all bugs.

> All we need is a little bridge across these two islands so that we can walk to
> your side and help.

Eh. We don't need "a little bridge". We need 60 hours days. 
More contributors, less trollers.
Comment 204 Daniel Glazman (:glazou) 2004-03-19 00:02:52 PST
Closing (see comment #201).
Comment 205 R.K.Aa. 2004-07-04 18:18:47 PDT
*** Bug 249692 has been marked as a duplicate of this bug. ***
Comment 206 Dan Cryer 2005-05-01 08:20:17 PDT
I was wondering, have we gotten any closer to a working contentEditable solution?
Comment 207 Andrew Mayo 2005-05-05 07:46:01 PDT
(In reply to comment #206)
> I was wondering, have we gotten any closer to a working contentEditable solution?

It's unfortunate that scanning this case I don't recall seeing anyone mention
the killer reason for having something like contentEditable.

This is to allow Mozilla to become the 'universal canvas' for UI design across
platforms. With SVG as well, you can then design complex UI that is controlled
by an outside business application, written in something stronger than a script
language (e.g Java, Mono etc).

Commercially, this is what the company I work for has done. We use IE as the
rendering surface for our UI and we also use it as the print and reporting
engine (there's a 'DrawToDC' method that allows anything on the browser to be
sent to the printer, though I doubt Mozilla has anything directly comparable
with this.

The business logic communicates with the UI via Javascript (using execScript).
This provides a very elegant tiered layer which can be customised in the field.

Using behaviors we have UI widgets like tabbed dialogues etc (though XUL would
obviously be an acceptable replacement for that). But I need to be able to mark
individual fields contenteditable and I also need a working textRange object and
good Javascript hooks before I could consider doing anything like this outside
of IE.

So that's the real reason for contentEditable; not just in-place HTML editing of
web pages. In our application, in fact, all HTML is loaded from local files. But
HTML provides everything that Avalon promises - only here and now. 

PS: If I had to vote, I would much prefer contentEditable was a style, so that I
could use CSS to control which fields are enabled rather than have the rather
ugly contenteditable=true attribute.
Comment 208 Magnus Melin 2006-01-04 08:36:43 PST
*** Bug 322335 has been marked as a duplicate of this bug. ***
Comment 209 Jesse Ruderman 2006-06-05 04:38:55 PDT
*** Bug 340375 has been marked as a duplicate of this bug. ***
Comment 210 Jesse Ruderman 2007-07-13 23:40:30 PDT
Fixed on trunk in bug 237964, so unless something surprising happens, this will be in of Firefox 3.

*** This bug has been marked as a duplicate of bug 237964 ***

Note You need to log in before you can comment on or make changes to this bug.