Opened 10 years ago

Closed 10 years ago

#174 closed Bug (fixed)

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

Reported by: saul11@… Owned by: martinkou
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 10 years ago by fredck

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 follow-up: Changed 10 years ago by fredck

  • Reporter changed from fredck to saul11@…

comment:3 in reply to: ↑ 2 Changed 10 years ago by catchsrinik

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 10 years ago by fredck

  • Milestone set to FCKeditor 2.5

comment:5 Changed 10 years ago by martinkou

  • Owner set to martinkou
  • Status changed from new to assigned

comment:6 Changed 10 years ago by martinkou

  • Resolution set to fixed
  • Status changed from assigned to closed

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 – 2016 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy