The comments brought over from the radar bug are a little out of date, we support getRangeAt now. Bold/Italic/Underline all work now. However: 1) "Undefined Value" is logged to the console as you caret through the editable area 2) The Cut button doesn't work (nothing logged to the console 3) Most of the pop-up palettes don't work (A dialog with this error comes up: tinyMCE object reference not found from popup.)

See this bug's dependancies for tasks to work on.

I just filed two bugs in TinyMCE (those rubes use Sourceforge): <http://sourceforge.net/tracker/index.php?func=detail&aid=1417116&group_id=103281&atid=635682> Safari support: selection jumps before execCommand <http://sourceforge.net/tracker/index.php?func=detail&aid=1417092&group_id=103281&atid=635682> Bug in Safari special casing for selections

I've recently encountered two HTML editors that work very well in Safari: http://editor.asbrusoft.com/ http://www.qwebeditor.com/ Both of their demos are riddled with validation errors, but they still both work very nicely. I suspect that authors of TinyMCE and FCKEditor could do worse than take a look at them.

TinyMCE is a fast, feature rich, cross-platform WYSIWYG editor, and its LGPL ("free"). We could start to add workarounds for all the functionality Safari hasn't yet implemented, but it wouldn't make TinyMCE a better software cause of the overhead. TinyMCE is bundled together in hundreds of commercial and non-commercial CMS I dare to say its the most used WYSIWYG editor today. From our point of view its simply not worth spending more time with Safari and TinyMCE at this point, the userbase for Safari is small, and the work related to get it to work at a level we would be satisfied with is just to much and it shouldn't be needed. Now before I get critisized for the "userbase" comment, bare in mind that Opera, that has an even smaller user base than Safari, is supported by TinyMCE. They have made excellent improvments in their support for WYSIWYG editors. We had a direct dialog with their developers, but that was just for a few quirks, most of TinyMCE was working already (Opera 9.0 Preview 1). As a side note, they actually implemented CSS3 Opacity features cause we asked them, it wasn't planned for 9.0 (we use it to dim the toolbar buttons). The editors Marcus Bointon point out working in Safari is just barly hanging in there (and are crappy in other ways), we had similar support a while ago, storing away the selection when the user clicks on a button in the toolbar (cause its lost in Safari, but not in any other browser), and then putting it back again and performing the operation. With the implementation of the getRangeAt functionality in one of the nightly builds we removed that logic, this did break backwardscompatiblity though. Those editors he mention are also commercial, sure, if someone offer to pays us to do the workarounds it might happen. Here are a few pointers for you. 1) Make your own test editor (Like the Midas demo that Mozilla has). 2) Write up some documentation on what is actually implemented. 3) Look at the WHATWG papers for guidelines. 4) When all else fails do it like Mozilla/Firefox. We sent in a few bugreports a while ago. http://bugzilla.opendarwin.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=tinymce We are avalible for discussion if you have questions, send me an email (not to spam at moxiecode dot com, but to joakim at same domain). Good luck, we are watching!

The following TinyMCE bug is also a blocker: https://sourceforge.net/tracker/index.php?func=detail&aid=1440124&group_id=103281&atid=635682

I am going to resolve all blockers of this bug fixed with the combination of TOT WebKit and the latest development sources of TinyMCE. I think the TinyMCE bugs noted here are sufficient to represent the blockage.

I could be way off here (just getting to grips with the code), but the problem with the selection being lost could be easily fixed in Frame.cpp, line 1920: if (shouldChangeSelection(newSelection) && newSelection.functionToCheckIfThisIsText() ) selectionController()->setSelection(newSelection); Just need some way of checking if newSelection is text, as the selection should only be cleared on mouse down on text? Problem is, i have no idea how to do this :) Then again, maybe this is too simple and I'm missing something ... ?

Noted that the WYSIWYG HTML Compose functionalitiy of www.vox.com (VOX) does not work and fails at lines in js files doing this.savedSelection = selection.getRangeAt(0).cloneRange();. Suspect this set of issues is similar to the TinyMCE issues being worked here perhaps? Note bug: http://bugs.webkit.org/show_bug.cgi?id=10165

Is there any hope of the few remaining blockers being fixed before Safari 3 final ships? What I mean is, what kind of priority do these TinyMCE-related bugs have in the grand scheme of things? Also, is there anything specific that someone unfamiliar with the code could do for these few bugs? I know what generally needs to be done, but these bugs have all been identified & verified ... so what's left to do besides digging into the code?

Just to add to this bug comment, TinyMCE is used by most CMS's out there! Joomla is one with 10' of thousands of sites built with it. I'm so tired of having to fire up Camino to just edit content. I would like this problem to be solved in this release of webkit and not have to wait for Safari 5 or 6 before this is resolved. Every browser supports it except Webkit. Even Opera does now.. ewwww....

(In reply to comment #11) > Just to add to this bug comment, TinyMCE is used by most CMS's out there! > Joomla is one with 10' of thousands of sites built with it. I'm so tired of > having to fire up Camino to just edit content. I would like this problem to be > solved in this release of webkit and not have to wait for Safari 5 or 6 before > this is resolved. Every browser supports it except Webkit. Even Opera does > now.. ewwww.... > And you have forgotten Moodle. "It has a significant user base with 25,281 registered sites with 10,405,167 users in 1,023,914 courses (as of May 13, 2007)". You must switch to FF or for answering students perfectly well formatted messages with a decent, non plain, html text. Sad.

Sorry. I don't understand the problem. Safari 3.1 works as a charm with any of these: http://tinymce.moxiecode.com/example_full.php?example=true http://editor.asbrusoft.com/page.jsp/id=3466?version=WCE http://www.qwebeditor.com/module.php?name=content&page=example1 Why when in the different courses and versions of Moodle I am a user (teacher), I can't see the editor and must switch to FF??

> Why when in the different courses and versions of Moodle I am a user (teacher), > I can't see the editor and must switch to FF?? See <http://bugs.webkit.org/show_bug.cgi?id=13229>