Opened 17 years ago

Closed 16 years ago

#174 closed Bug (fixed)

"Maximize the editor size" button can't handle relative DIVs

Reported by: saul11@… Owned by: Martin Kou
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: FCKeditor 2.4
Keywords: SF Cc:


The "maximize the editor size" button isn't working perfectly. It won't position the editor top left when it's in a relative positioned div. See my test page for the wrong behavior:

Just scroll down or click 'demo' and click the maximize button.

I also encountered this problem when first developing the button. The button as it was first released as a plugin ( does position the editor properly. Maybe this code can still be of any use...

Moved from SF:

Change History (6)

comment:1 Changed 17 years ago by Frederico Caldeira Knabben

The maximize code has been changed many times after the first release because of issues regarding absolutely and relatively positioned elements. It seams that you are bringing another case to be handled. We'll check it... a reduced test case must be created first of all.

Thanks for the report.

comment:2 Changed 17 years ago by Frederico Caldeira Knabben

Reporter: changed from Frederico Caldeira Knabben to saul11@…

comment:3 in reply to:  2 Changed 17 years ago by Srinivas

Replying to fredck: We are having the same problem. Could you please let us know which module is fixed here, so that we will take only that version , instead of upgrading . we have tight dead lines here.

comment:4 Changed 17 years ago by Frederico Caldeira Knabben

Milestone: FCKeditor 2.5

comment:5 Changed 16 years ago by Martin Kou

Owner: set to Martin Kou
Status: newassigned

comment:6 Changed 16 years ago by Martin Kou

Resolution: fixed
Status: assignedclosed

This has to do with the fact that the function FCKTools.SaveStyles() ignores CSS styles associated by element IDs.

What happened when the "Maximize" button was clicked in Saulmade's example was that, the maximize function cleared the inline styles and class-associated styles for all ancestor nodes of the FCKeditor widget. But it did not clear the styles associated by element IDs. In this sense, the scope of this bug is not limited to relative positioned DIVs, any leftover styles in the editor widget's ancestor nodes that are associated by element IDs, could possibly affect the appearance of the editor in maximized mode. For example, absolute positioning could trigger a similar effect:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html class="" lang="en" xml:lang="en" xmlns="">
                <title>Test case for bug #174</title>
                <script src="../fckeditor/fckeditor.js" type="text/javascript"></script>
                                position: absolute; width: 900px; height: 600px; overflow: visible; top: 20px; left: 100px;
                <div id="upper">
                        <form method="POST" action="somewhere_out_there">
                                <script type="text/javascript">
                                        var editor1 = new FCKeditor("editor1");
                                        editor1.BasePath = "/fckeditor/";
                                        editor1.Height = 300;
                                        editor1.Value = "Am I in the correct position?";

It could be unwise to clear the element ID values just like the class ID and inline style values, however. Since many modern JavaScript toolkits rely heavily on element IDs in their programming logic. ( e.g. the $() function in Prototype toolkit ). Clearing away element IDs might break the web page containing FCKeditor.

I've made a fix for the full screen widget positioning in change set [487], which should fix Saulmade's problem. However, there may be other ID-associated style attributes that could trigger other bugs.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy