[webkit-dev] Reporting FCKeditor related bugs
mjs at apple.com
Fri Jan 12 15:36:10 PST 2007
On Jan 12, 2007, at 6:36 AM, David D. Kilzer wrote:
> Hi FredCK,
> I'd recommend filing all of the bugs. That way if someone else
> gets the notion to create a reduced test case or fix the bug,
> that's less work you'll have to do in the long run!
> Please do a cursory search for existing bugs before filing new ones
> as well. For example, "links are clickable in the editing area"
> may be similar to Bug 11297. (It took me three searches to find
> that one, though, so don't spend all your time search for pre-
> existing bugs!) It's better to have the bugs documented and later
> marked RESOLVED/DUPLICATE than to not have them documented at all.
I agree with Dave's suggestion. Having the bugs filed is more
important than level of detail in the bug. We will likely need
reductions for these at some point to be able to fix them, but those
don't have to be done at the same time or even by the same person as
originally filing the bug.
> On Jan 12, 2007, at 4:40 AM, Frederico Caldeira Knabben wrote:
>> It is really nice to see that FCKeditor is almost running with the
>> There are still some bugs, and before I do any move, I would like
>> to be sure
>> this is something acceptable.
>> I've always tried to create bug reports whithout associating them to
>> FCKeditor. I simply got a buggy thing in the editor, and reducted
>> it as much
>> as possible to generate precise reports.
>> All we know how reductions are important. And we also know that their
>> creation take a lot of time. So, the report of bugs were going
>> pretty slow.
>> I've noted instead that, for the TinyMCE editor, there are many
>> generic bugs
>> strictly specifying TinyMCE compatibility. Something like
>> "TinyMCE: Format
>> pulldown doesn't work". Those reports have not so much
>> information. Many
>> times just a line of descrition of the bug.
>> I have a list of bugs of FCKeditor with Safari. Should I start
>> simple "FCKeditor: ..." reports for all of them?
>> In these way we would all have a clear compatibility status, and
>> in the mean
>> time myself, and others interested would be working for the
>> Thanks for the information,
>> PS: The following are the current known bugs:
>> - links are clickable in the editing area
>> - the "Save" button doesn't update the hidden field before posting
>> - bogus <br> remain in the code
>> - "Templates" doesn't work when inserting in the cursor position
>> - paste buttons are always disabled
>> - find dialog doesn't work
>> - "Remove Format" button adds Apple tag to the code
>> - enter key inside forms create further forms.
>> - hidden fields doesn't show up
>> - <span class="Apple-style-span"> when formatting
>> - <hr>, <ul> and <ol> have id="undefined"
>> - the "Link" dialog is not loading correctly
>> - objects are not selectable and dragable
>> - "Insert Special Char" doesn't work
>> - the "Size" toolbar combo has no effect in text
>> - panels on toolbar items are positioned wrongly
>> - panels are not hidden when clicking outside them
>> - context menu icons are not showing
>> - tables are compressed on creation
>> - form fields are enabled in the editing area
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev