Opened 18 years ago
Closed 17 years ago
#174 closed Bug (fixed)
"Maximize the editor size" button can't handle relative DIVs
Reported by: | Owned by: | Martin Kou | |
---|---|---|---|
Priority: | Normal | Milestone: | FCKeditor 2.5 Beta |
Component: | General | Version: | FCKeditor 2.4 |
Keywords: | SF | Cc: |
Description
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:
http://www.saulmade.nl/FCKeditor/FCKTest.php
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 (http://www.saulmade.nl/FCKeditor/FCKPlugins.php) does position the editor properly. Maybe this code can still be of any use...
Moved from SF:
http://sourceforge.net/tracker/index.php?func=detail&aid=1648925&group_id=75348&atid=543653
Change History (6)
comment:1 Changed 18 years ago by
comment:2 follow-up: 3 Changed 18 years ago by
Reporter: | changed from Frederico Caldeira Knabben to saul11@… |
---|
comment:3 Changed 17 years ago by
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
Milestone: | → FCKeditor 2.5 |
---|
comment:5 Changed 17 years ago by
Owner: | set to Martin Kou |
---|---|
Status: | new → assigned |
comment:6 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → 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" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html class="" lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Test case for bug #174</title> <script src="../fckeditor/fckeditor.js" type="text/javascript"></script> <style> #upper { position: absolute; width: 900px; height: 600px; overflow: visible; top: 20px; left: 100px; } </style> </head> <body> <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?"; editor1.Create(); </script> </form> </div> </body> </html>
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.
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.