Hello all you guys,
Version 2.1 is about to come. It is another important step to the project. It introduces many bug fixings and some new features. You can see Whats New? here:
http://www.fckeditor.net/_temp/FCKedito ... tsnew.html
You can see it online here:
http://www.fckeditor.net/_temp/FCKedito ... /_samples/
And download the unofficial ZIP:
http://www.fckeditor.net/_temp/FCKeditor_2.1PR_Test.zip
I would like to ask all you to participate and test this version as much as you can, even online and downloading the zip and installing on your server or projects for testing. Only doing this we can guarantee that no big issues will be introduced when officially publishing it.
With this version we are attempting to finally solve the <ENTER> behavior in Firefox to make it produce <p> tags instead of the <br> (thanks to a huge contribution from Goss Interactive Ltd). So I would ask you to make more attention to Firefox.
As always, I would ask you to please use this forum thread to report bugs or suggestions on it. Please dont make references to already known bugs and suggestion, but only things that have been introduced with this version.
This is important to guarantee quality, so please participate. Thanks in advance.
Best regards,
FredCK
Thu, 10/06/2005 - 03:06
#1
RE: TESTERS CALLED: Version 2.1 Preview
I found some problems, hope you can fix this as well:
Code to reproduce most are included
Tested in FCKeditor 2.1 on XP in FF 1.06 and IE 6.0
Problem 1:
P tags are handled different in IE and FF:
If you insert som new-lines in IE and save to database.
Then those new-lines are stored as:
<p> </p>
<p> </p>
<p> </p>
If you now open same content in FF then those new-lines are like this:
<p> </p>
<p> </p>
<p> </p>
The empty P tags are not possible to remove in FF by normal editing like backspace or left-click+drag.
The content also looks different since the space are not added in FF.
Problem 2:
If you insert a table inside a DIV then IE display some extra
space after the table if the WIDTH property are set for the DIV.
This can be observed in IE but not in FF.
See attached code below for testing. The first works as it should.
The second uses the WIDTH property in DIV and is buggy:
<div style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 12px; PADDING-BOTTOM: 0px; MARGIN: 0px; COLOR: white; PADDING-TOP: 0px; FONT-FAMILY: arial; BACKGROUND-COLOR: gray">
<table cellspacing="0" cellpadding="0" width="100%" border="1">
<tbody>
<tr>
<td style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px">This DIV TABLE combination has no spacing problem in IE<br /><br />This DIV is not using the WIDTH property</td>
</tr>
</tbody>
</table>
</div>
<p> </p>
<div style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 12px; PADDING-BOTTOM: 0px; MARGIN: 0px; WIDTH: 50%; COLOR: white; PADDING-TOP: 0px; FONT-FAMILY: arial; BACKGROUND-COLOR: gray">
<table cellspacing="0" cellpadding="0" width="100%" border="1">
<tbody>
<tr>
<td style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px">This DIV TABLE combination HAS A SPACING PROBLEM in IE. There is an extra space in the DIV after the TABLE.<br /><br />This DIV is using the WIDTH property</td>
</tr>
</tbody>
</table>
</div>
Problem 3:
Floating DIV are sometimes clipped in IE:
Explanation on how to reproduce in code below.
Just paste code below into editor and follow guidelines:
<div style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 12px; FLOAT: right; PADDING-BOTTOM: 0px; MARGIN: 0px; WIDTH: 50%; COLOR: white; PADDING-TOP: 0px; FONT-FAMILY: arial; BACKGROUND-COLOR: gray">
<table cellspacing="0" cellpadding="0" width="100%" border="1">
<tbody>
<tr>
<td style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px">
<p><strong>DIV clipping problem in IE.</strong><br />This DIV has the properties FLOAT and WIDTH set.</p>
<p>If you place the cursor after the letter in line left of DIV and hit CTRL numerous times, as well as BACKSPACE to remove the same CTRL then you can sometimes experience clipping of this DIV.</p>
<p>Insert at least 3 or 4 CTRL after line to left of div.<br />Same problem for both CTRL and SHIFT+CTRL<br /><br />If text left of DIV extends the bottom of this div then the problem is gone.</p>
</td>
</tr>
</tbody>
</table>
</div>
<p>Insert cursor after this line and press CTRL from 2 to 4 times of more... as well as BACKSPACE.</p>
Problem 4:
Placing cursor ouside DIV if DIV is only content in editor is difficult (impossible ?).
Problem in FF, not in IE:
Paste code below in editor in FF and try to place cursor outside the DIV.
<div style="margin: 0px; padding: 0px; font-size: 12px; float: left; width: 50%; color: white; font-family: arial; background-color: gray;">
<table width="100%" cellspacing="0" cellpadding="0" border="1">
<tbody>
<tr>
<td style="padding: 10px;"><strong>Cursor placement in FF problematic</strong><br /><br />Try to place the cursor outside of this DIV in FF. Not possible, if DIV are the only content. Works find in IE.<br /></td>
</tr>
</tbody>
</table>
</div>
Problem 5:
Deleting of DIV are sometimes difficult: only tested in IE.
In IE
BACKSPACE have no effect on the DIV from the outside.
In FF
Instead of deleting DIV cursor pops into the content of DIV.
Insert code below into editor and try it:
<div style="margin: 0px; padding: 0px; font-size: 12px; float: left; width: 50%; color: white; font-family: arial; background-color: gray;">
<table width="100%" cellspacing="0" cellpadding="0" border="1">
<tbody>
<tr>
<td style="padding: 10px;">
<p><strong>Deletion of DIV with backspace</strong><br /><br />Place cursor after text outside DIV and hit backspace. <br />In IE, BACKSPACE have no effect on the DIV.<br />In FF the BACKSPACE causes cursor to pop inside content of DIV.</p>
</td>
</tr>
</tbody>
</table>
</div>
<p>Place cursor after this text and hit BACKSPACE to try to remove the DIV</p>
Problem 6:
Increase Indent, Decrease Indent handled different in IE and FF.
Tested on this plain text only: Increase Indent test
In FF:
Select text (Increase Indent test) and click on Increase Indent button creates:
<blockquote>Increase Indent test</blockquote>
A new selection an click on Decrease Indent produces
Increase Indent test
If I open the blockquoted text in IE and places cursor inside the text and hit Decrease Indent then the result is:
<p>Increase Indent test</p>
In IE:
Select plain text (Increase Indent test) and click on Increase Indent button creates:
<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
<p>Increase Indent test</p>
</blockquote>
(** NOTE:
If I save this content and open in FF and hit Decrease Indent the result is:
<blockquote dir="ltr" style="margin-right: 0px;"> </blockquote>
<p>Increase Indent test</p>
<blockquote dir="ltr" style="margin-right: 0px;"> </blockquote>
**)
I then select the text (which first was produced in IE by clicking Increase Indent) in IE and click on Decrease Indent which produces:
<p dir="ltr" style="MARGIN-RIGHT: 0px">Increase Indent test</p>
Then I place the cursor in the text again and select Increase Indent again which produces:
<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
<p dir="ltr" style="MARGIN-RIGHT: 0px">Increase Indent test</p>
</blockquote>
Which differ from the first blockquote inserted in IE...
Problem 7:
Justify differences between IE and FF.
Tested on plain text: Block justify test
In FF
Select the text (Block justify test) and click on Right Justify button.. it produces:
<div align="right">Block justify test</div>
If I then select text again and click on Left Justify button then it produces:
<div align="left">Block justify test</div>
In IE
Select the plain text (Block justify text) and click on Right Justiry button.. it produces:
<p align="right">Block Justify test</p>
Okay... both IE and FF understand and handles both implementations but is there a reason for not using same code (TAG) when using different browsers.
Using classes might be easier when you know that same (button click) produce the same code.
Problem 7:
BOLD, ITALIC, UNDERLINE
This is really minor but..anyway
Both IE and FF now uses same STRONG, EM and U ... great.
They are put around text in same order but it works.
In FF:
After you have applied one or more of the above to plain text (only tested on plain text):
If you place cursor in styled text and then clicks one or more of the highlighted buttons for STRIKE, EM, U (Bold, Italic, Underline)
then the style are not removed. It works if you select the whole text.
In IE:
Same as for FF but works a little different for deselcting Bold.
If you place cursor inside the styled sentence only the word that the cursor is placed within get destyled.
Works okay if you select whole text thouhg..
Problem 8:
Why implement "Insert Horizontal line" as:
<hr width="100%" size="2" />
and not as:
<hr />
Just belives the latter one will make easier to use with classes.
RE: TESTERS CALLED: Version 2.1 Preview
Applying custom styles below (SPAN) within a P tag and then removing the style agian, removes BR tags within that P tag in FF.
Also... In FF you can just place cusor somewhere witin the newly applied SPAN styling and
deselect that style by selecting same style from the Style dropdown, or you can select all text and do the same.
In IE you have to select whole text to deselect the style.
Here are the custom Style definitions I tested with:
(I guess that this happen with all similar SPAN implementation)
<Style name="LineHeight=200%" element="span">
<Attribute name="style" value="line-height: 200%;" />
</Style>
<Style name="FontSize=150%" element="span">
<Attribute name="style" value="font-size: 150%;" />
</Style>
Here are code to test with ... insert into editor and try out in FF:
<p>If you enter some lines in a paragraph in FF<br />with BR tags between the lines<br />and then select text in that paragraph in FF<br />and apply a custom style which inserts this:<br />A SPAN with line-height:200%<br />Or A SPAN with font-size:150%<br />Or I would guess any SPAN applied same way.....<br />around the selected text.<br />If you now select the same text again and deselect<br />that styling (using the style dropdown) all the<br />BR tags are removed in FF.<br /></p>
RE: TESTERS CALLED: Version 2.1 Preview
Problem 1: Background color for plain text and paragraphs behaves different in FF and IE:
In IE implements this using the FONT tag and it works... like this: (It works in IE)
<p><font style="BACKGROUND-COLOR: #0000ff">Background color test</font></p>
and same for plain text but without the P tags.
FF: Not able to set background color for a P section or for plain text.
I would prefer use of SPAN tag since FONT are deprecated.
"Problem" 2:Text color behaves same in IE and FF but....
Text color are implemented using FONT tag like this:
<font color="#0000ff">Try this color</font>
I thought the FONT tag was deprecated....
Is there a reason for not using the SPAN tag?
RE: TESTERS CALLED: Version 2.1 Preview
I agree with the font/span thing. "font" is just /so/ 20th century.
I don't have the time at the moment to give a lot of attention to the editor, but first thing is that it does not work at all in Konqueror, and therefore will most likely not work in Safari either.
That is understandable, as the source seems to specifically target only Gecko and IE.
It is probably far too late in the game to change, but can I ask why the code was written for specific browsers, as opposed to for the level of technology that the browser supports?
For example, it is considered bad practice these days to sniff for browsers. Most developers opt to assume that the browser supports DOM, and provide backwards-compatible failsafes for those browsers that still insist on clubbing their women and living in caves.
The first item on the what's new list actually answers the question I posted on the forum last week about using external objects - I can write a plug-in now based around it - thanks!
If I get the time, I will start work on a KHTML version of the script tomorrow, to help out in the project. As it's my primary browser when I'm at home, I'll also be helping myself
Kae
RE: TESTERS CALLED: Version 2.1 Preview
like, I wish needing to know what browser wasn't, like, necessary in this enlightened age, but, like, Im' pretty sure that untill browsers are actually, like, cross-renderable, it's, like, _so_ necessary.
See the css box bug with IE for example, or the aforementioned z-index problem, or a slew of other not-quite-standards-based problems.
Like the <font> issue. That really stems from the browser, not the JS. FF for some reason uses deprecated markup. A newer version probably won't, some day.
So we either write custom hooks for, like, everything (slooooooooow) or rely on the browsers and some regex's and hope the different rendering engines get it together.
Gecko and IE just happen to be by far the "common denominators".
If you know of a RTE that doesn't browser sniff, and renders the same across browsers, I'd be interested... heck, if you know of web pages with some level of complication, that don't render different accross browsers (without sniffing), I'd be interested.
Love the idea of a KHTML version. LOVE IT LOVE IT.
I think the latest version of safari actually supports the editableArea or whatever, but I don't know if they are using KHTML for that aspect still. I think not. Last I checked a RTE that worked in Konqueror didn't work in safari. NOTHING worked in safari. Their implimentation was broke. So there is an instance of where you might get misleading results if you just tested the DOM.
So there is even greater need for the majic non-sniffing cross-working whatnot!
RE: TESTERS CALLED: Version 2.1 Preview
Hi Kae,
My name is Ben, and my job on this project is to answer this question
It is easy to deal with browser quirks when outputing web pages. Yes there are some differences, however well structured (x)HTML and CSS can generally be written to work consistently in all modern browsers.
However, FCKeditor (and all other javascript based editors) has to deal with much more than rendering quirks. IE and Gecko implement quite different and proprietary editable areas which are not part of the DOM standard at all. If you look at the code you'll see the methods used for implementing editor tasks are often vastly different.
This is also why there are such differences in the way the editor works in IE and Firefox. It's not FCK, it's the underlying support in the browser that is just different.
What that means is that there is no way to write a truly cross-browser web based editor with a single set of code (unless you use Java, ergh). Other javascript based editors (HtmlArea, TinyMCE etc) might not seperate the code out as logically as Fred has, but they all "sniff" for the browser and work accordingly. Personally I think the way it is structured is sensible, as it is much lighter and faster for the end user.
Word on the street is that Safari has recently added support for editable areas, and this has already been slated as next for FCK (a bit premature until the current browsers are rock solid IMHO). I'm pretty sure Safari has implement it's editable area differently to both IE and Mozilla, or at least it will have quirks. And since the codebase was split some time ago, Konqueror will probably be different again
So until there is a standard dictating how browsers are to offer in-place editing ability, we're stuck with clubbing our women and living in caves!
RE: TESTERS CALLED: Version 2.1 Preview
That's fair enough, Ben.
I guess, in some cases, it is much easier to separate by browser than by capability.
The reason I brought it up, is that I do plan on starting on the KHTML version today, and I'm almost certain that it will involve a lot of redundancy, with the code virtually interchangeable with the Gecko code - that means that if a bug is discovered in one piece of code, then the bug will need to be fixed in two areas.
Time will tell - who knows, this may be a non-issue.
btw: as far as I know, Gecko also has contentEditable. Also, I'm watching their text-shadow bug (https://bugzilla.mozilla.org/show_bug.cgi?id=10713), and it looks like the next release will have it. Safari and KHTML already have this. I expect IE7 will also have it. Should there be a new button for this in FCKEditor?
RE: TESTERS CALLED: Version 2.1 Preview
Font format dropdown doesn't show the format of the currently selected block in IE.
RE: TESTERS CALLED: Version 2.1 Preview
> of the currently selected block in IE.
Yeah this one is annoying ... although it has always been there.
I hope it can be fixed, it works nicely on Firefox!
RE: TESTERS CALLED: Version 2.1 Preview
The newly introduced:
FCKConfig.ProtectedSource.Add(...)
is really handy piece of work.
Is it possible to create something similar for visible tags in the editor?
For example:
Let say you let your users insert premade code into the editor ... maybe a DIV with a couple of other elements within.... One H3 tag and one table with one cell.
Then say you want a rules like this:
The user should be able to edit text widthin the h3 tag.
The user should be able to edit text widthin the td tag of the table and table.
The user should not be able to delete h3 tag.
The user should not be able to delete table.
The user should be able to delete the DIV tag, but then also deleting all content widthin that tag.
The user should not be able to insert text/edit within the DIV tag and outside the h3 or table tag.
Could maybe be implemented by using this within the tags:
fckedit="no"
which means that editing directly inside tag is not allowed, but editing within sub tags may be allowed (which depends if fckedit="no" are used on subtags or not)
fckdelete="no"
Which means deletion of that single tag is not allowed directly, but should be deleted if parent tag are.
And then if FCK writes some code to obey the rules .... well it might work.... and should opt for some new possibilities...
Se example code below.... and if you have some thoughts about this ...well.....
<div fckedit="no" class="someclass">
<h3 fckdelete="no">Title here</h3>
<table fckdelete="no" width="100%" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td>
<p>Text here</p>
</td>
</tr>
</tbody>
</table>
</div>
RE: TESTERS CALLED: Version 2.1 Preview
Hi,
Thank you very much FREDCK !
I have noticed this important bug on FIREFOX : BaseHref configuration dont work (work good on IE). (Its not working under the editor but its ok on the preview window)
Otherwise there is a second problem with FIREFOX and IE in the preview function of the images and flash windows when BaseHref is set. Personally i have fixed this problem :
Open fck_images.js and fck_flash.js
in UpdateImage and UpdatePreview function :
replace : e.src = GetE('txtUrl').value ;
by :
var url = GetE('txtUrl').value;
if (url.indexOf('http:') == -1)
e.src = FCKConfig.BaseHref + url ;
else
e.src = url;
Other problem : the relative links was not detected in the link window. i have fixed this problem :
Replace : oRegex.UrlOnChangeTestOther.compile( '^(javascript:|#|/)', 'gi' ) ;
By : oRegex.UrlOnChangeTestOther.compile( '^(javascript:|#|/|../|[-a-z_]*/)', 'gi' ) ;
Martin
RE: TESTERS CALLED: Version 2.1 Preview
oRegex.UrlOnChangeTestOther.compile( '^(javascript:|#|/)', 'gi' ) ;
by
oRegex.UrlOnChangeTestOther.compile( '^(javascript:|#|/|../|[-a-z0-9_.]*/)', 'gi' ) ;
RE: TESTERS CALLED: Version 2.1 Preview
and hitting space button inside editor after the button-click causes the onclick event for button to fire (only observed in IE).
How to reproduce:
a. Write some text inside editor.
b. After the last letter written in editor, click on a button in the main page
(I have tested by clicking a button that opens a new window, and also a button that resizes the editor area).
c. If it is a button that opens a new window.. and you just close it again then the cursor is still visible after last written letter in editor,
and you can start writing inside editor without clicking inside it first. Do not klick any place before writing.
d. Or if it is a button .. let say that just adjust the editor width (button outside the editor), then you can start write where you
previously left, inside editor, without clicking any place inside the editor first.
If you do either 3 or 4 above you will trigger the onclick event for the button on every hit on the SPACE key when you are writing inside editor.
Annoying and confusing for the user.
2. Problem with selected objects in IE that object markings are showing outside the editor area and above
elements in the page that holds the editor... that is if the object you have selected are partly scrolled up or down in editor.
3. Font and font size are using the FONT tag. Why not the SPAN tag?
Font (from font dropdown) in FF are implemented like this:
<font face="Times New Roman">Font test</font>
Size (from size dropdown) in FF are implemented like this:
<font size="5">Size</font>
Same here: Why use FONT and not SPAN?
FONT are deprecated.
RE: TESTERS CALLED: Version 2.1 Preview
Can you alo make it fix the problem of correcting <somtag /> to <sometag></sometag> ?
Some programmers would rather have there tags remain the way they have entered it
RE: TESTERS CALLED: Version 2.1 Preview
Being able to set an FCKeditor variable for BODY className before the editor is loaded(initialized), and to do it without any dirty hack. Would like this to be in the FCKeditor core code.
I uses classes for the body tag to make it easy for the users to get the basic styling for most used stuff.
Being able to use a class for the BODY of FCKeditor is handy because that is what I'm using on the site.
To make this work as FCKeditor is today I have to set className of BODY of editor AFTER the editor has loaded. (and without any hacking into code)
So after the editor has loaded I call this custom function which is in main page:
function switchClass(theclass){
var oFCK;
if (navigator.appName=="Netscape")
oFCK = MyTextarea___Frame.contentWindow;
else
oFCK = MyTextarea___Frame;
oFCK.FCK.EditorDocument.body.className= theclass;
}
And then the user can switch class for the BODY at any time using a dropdown that is placed outside the editor..
NOT being able to set the className (tell the editor what class should be used on startup) before the editor has loaded, makes the content in the editor first load in another style setting and then only after editor has finished loading, my switchClass function is called and the appropriate class applied.
This makes the content "flash" when the class are changed. I do not want that.
I guess it is pretty easy (for the developers) to change the core code, to make it possible to set an appropriate FCKeditor className variable before
oFCKeditor.ReplaceTextarea();
is called and then make the editor load with the defined class.
I would prefer to be able to do this in the page where the FCKeditor is placed. Maybe would be nice being able to optionally set a similar variable in fckconfig.js
Would really like to see that in core code of FCKeditor as well.
RE: TESTERS CALLED: Version 2.1 Preview
Did you manage to get my fix for this working?
RE: TESTERS CALLED: Version 2.1 Preview
Thanks for your tests. I ask you to please continue with it.
As far as I can see, there are not big problems for the 2.1 launch.
Also, I'll not include further features on this version. There will be a 2.2, 2.3 and so on for that.
I just want to confirm that there are no generic bugs "introduced" by this version (like the anchor links problem with the 2.0).
Thanks again,
FredCK
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: TESTERS CALLED: Version 2.1 Preview
If the bug of BaseHref on FIREFOX is corrected I think that I risk to be so happy that I am doubtless going to make a mistake and to empty my bank account:)
FIREFOX is the only compatible navigator MAC
RE: TESTERS CALLED: Version 2.1 Preview
FCK
There is ONE MAJOR bug in 2.1
Se my previous post.
One other guy also confirmed the same major bug.
By some reason your post are now listed here after those two replies even if those post where posted after your posting.
The two posts I refere to are:
By: bngobngo - bngobngo
RE: TESTERS CALLED: Version 2.1 Preview
2005-09-29 15:23
By: Andre Schild - aschild
RE: TESTERS CALLED: Version 2.1 Preview
2005-09-29 15:55
And then comes your post that was posted before those:
By: Frederico Caldeira Knabben - fredckProject Admin
RE: TESTERS CALLED: Version 2.1 Preview
2005-09-29 14:49
See the time when those are posted.
I do not understand why your post are listed after those postings.
Would also be nice to get a confirmation on that you also have seen this bug... IT IS A MAJOR BUG.
Find it strange that after using two full days of testing the 2.1 and reporting the findings here (at least one BIG bug) and to get feedback that there is no such...
I just hope that it was my writing that maybe was not precise enough.... and that you now will confirm this bug and fix it....
And then there is those DIV problems that I found... Not as big as the one above but very annoying.
Details about my findings are in my first post.
Anyway.. keep up the good work
RE: TESTERS CALLED: Version 2.1 Preview
BR,
FredCK
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: TESTERS CALLED: Version 2.1 Preview
I open the editor in IE.
Then hit the "New Page" button to clear all content.
Then I enter 3 CTRL, "Test" and 3 CTRL so the source look now like this:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
Then I submit the data to database.
After I have submitted the data to database. When I submit the submitted data will be fetched from DB and redisplayed in browser and editor. I hit the source button again to see that I have the same as I submitted above. Which I have.
All above was done in IE 6.0 on XP.
Then I open phpmyadmin and find the record I just saved. It contains this:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
Exactly same as I submitted. Would be strange though if this was not the same since fetching same record in IE show this in source.
Next is tested in Firefox 1.0.6
I open the same page as I tested using IE above.
Then I select the same record as I created in IE, and when I now look at the source I see this:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
I have now lost the " " part inside those empty paragraphs.
Then I save the record in Firefox back to DB by hitting submit. This also fetches the submitted data again from database and display it in editor.
When I look at the data in Firefox again after subission, data look like this:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
I now check the record in database again and it look like this:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
Then I open record in IE again and look at source, which look like this:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
So it looks like IE do some cleaning with those empty P tags fetched from DB.
NOTE: If I start all over in Firefox, empty the source and enter (I'm not pasting) same as when I started in IE then I see this in Firefox before submission to database:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
Then I get this in database:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
But when I submit to database in Firefox then my page also fetches the submitted data from DB and redisplay it as:
<p> </p>
<p> </p>
<p> </p>
<p>Test</p>
<p> </p>
<p> </p>
<p> </p>
And if I now submit... well you see the picture...
I installed the 2.1 on WinXP PRO without any changes to the default fckconfig.js except for:
As you can see, DB is not messing up the data and I use the same page to test this in IE and FF.
It works nicely in IE, IE even fixes empty P tags, created by Firefox, by entering " " into them again.
Firefox seem to have a taste for those " " and takes them away somewhere in load/initalizing process....
Sorry for this long post, I'm ultra-tired, it's very late here now... hope you manage to reproduce it.
Best regards
RE: TESTERS CALLED: Version 2.1 Preview
I installed the 2.1 on WinXP PRO without any changes to the default fckconfig.js except for:
some css file positioning.
Thanks for the thread tips on posting, I'll use that from now on
RE: TESTERS CALLED: Version 2.1 Preview
I consider problem 1 in my first post to be a BIG problem.
I repeat it here: Problem 1.
If you are working in IE, or in FF and enter some empty paragraphs
<p> </p>
and you save that to a database or whatever.
If you now open the same text in Firefox then all empty paragraphs now look like this:
<p></p>
which of course mess up you layout and those paragraphs are no longer editable in FF as well.
Looks to me that some code in FCKeditor change all the
<p> </p>
to
<p></p>
when the editor loads in FF.
Other stuff:
Then there are also some problems with how DIV tags are handled in IE which is really annoying while editing.
The worst case is when editing text which is placed left or right of a floating DIV. The DIV will often be clipped in IE while you are editing that text. (try insert multiple CTRL and BACKSPACE).
Second worst of DIV handling are that inserting let say some template code where you have a table inside a DIV, then there will be extra space after table but before the bottom part of the DIV. This can be seen in IE and not in FF. Seen in editor and not in resulting page. But makes it easy for users to enter text where they should not, since it is easy to place the cursor between the </TABLE> and the </DIV> and start entering text there.
See my first post for details.
RE: TESTERS CALLED: Version 2.1 Preview
I've just done a test creating an editor instance and setting its value like this:
oFCKeditor.Value = '<p> </p><p> </p><p> </p>' ;
All have been preserved. It could possibly a problem on your application that is decoding the data when retrieving it from the database. Please investigate it.
Are there anyone else facing this problem?
Thanks again. Regards,
FredCK
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
RE: TESTERS CALLED: Version 2.1 Preview
in ie 6 on xp,
hit enter and 2 paragrahs are inserted like so:
<p> </p>
<p> </p>
open same page in firefox 1.04 and 1.07
see the same
<p> </p>
<p> </p>
the > have not been stripped.
RE: TESTERS CALLED: Version 2.1 Preview
It should be possible to load text, (don't change anything) and save it back and still get the same content.
Unless of course some of the replace... settings are set in the editor.
Otherwise 2.1 looks good for us.
Andr
RE: TESTERS CALLED: Version 2.1 Preview
I did retest it, and I can't reproduce the problem. We invoke the editor that way, and the remains in the code.
<div><input type="hidden" id="DE_Text1_H" name="DE_Text1_H" value="<p>&nbsp;</p>
<p>Dies ist ein kleiner Ausschnitt aus meinen Fotos.<br /> Wenn Sie etwas bestimmtes suchen und hier nicht finden, senden Sie mir doch ein E-Mail. <br /> </p>
<h2>Die neuesten 10 Bilder</h2>"><input type="hidden" id="DE_Text1_H___Config" value="FlashBrowserURL=../filemanager/browser/default/browser.html?Type%3DFlash%26Connector%3D../../../../../../servlet/connectors/jsp/connector&ImageBrowserURL=../filemanager/browser/default/browser.html?Type%3DImage%26Connector%3D../../../../../../servlet/connectors/jsp/connector&customConfigurationsPath=fckconfig.js&Debug=true&AutoDetectLanguage=false&EditorAreaCSS=/peter-schild-webseite/tefiles/userstyles.css&DefaultLanguage=DE&StylesXmlPath=/peter-schild-webseite/tefiles/userstyles.xml"><iframe id="DE_Text1_H___Frame" src="fckeditor.2.1-B1/editor/fckeditor.html?InstanceName=DE_Text1_H&Toolbar=Aarcat2Source" width="600" height="300" frameborder="no" scrolling="no"></iframe></div>
bngobngo - can you show us the code you use to invoke the editor ?
Andr
RE: TESTERS CALLED: Version 2.1 Preview
Below I have pasted code for a PHP page for you to test the P tag bug that I get in FF.
To be able to test with code below you will have to create a database and a table in MySql.
Database structure are in top of file.
Just name the file fcktestgui2.php.
Code example below:
RE: TESTERS CALLED: Version 2.1 Preview
You may also want to see that I put out the database text like this in PHP:
echo "<textarea id=\"MyTextarea\" name=\"MyTextarea\">$cur_text</textarea>\n";
Where $cur_text are the text from database.
RE: TESTERS CALLED: Version 2.1 Preview
As I thought, it is an error in your code. You must never place HTML tags and entities inside a <TEXTAREA> without "htmlenconding" them.
So, replace your code with something like this:
echo "<textarea id=\"MyTextarea\" name=\"MyTextarea\">" . htmlspecialchars($cur_text) . "</textarea>\n";
Just to confirm... as far as I can see, this bug report is invalid right?
Best regards,
FredCK
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn