The text editor textarea is cut in half when using the Filtered HTML input format in Google Chrome or Safari. This problem does not occur when using the Full HTML input format, and is not an issue in Firefox, Internet Explorer, or Opera. Also it does not occur when using the Drupal FCKEditor module.
The textarea is full size when in Full HTML input format, and has the outline of full size when in Filtered HTML. However the space for typing is cut in half, as can be seen in the attached picture. It is made more clear in this situation since the body tag for our editor's CSS is shaded.
Using Drupal 5.19, FCKEditor 2.6.4.1, and WYSIWYG 5.x-2.0.
Comment | File | Size | Author |
---|---|---|---|
#15 | wysiwig fck in safari.jpg | 35.16 KB | cpelham |
#8 | wysiwyg-filtered-html-issue.png | 4.55 KB | ron_s |
#9 | wysiwyg-filtered-html-issue.png | 4.55 KB | ron_s |
wysiwyg-half-textarea.png | 64.73 KB | ron_s |
Comments
Comment #1
ron_s CreditAttribution: ron_s commentedSorry, this is documented for 5.x, not 6.x.
Comment #2
redpuma CreditAttribution: redpuma commentedI'll add that this also happens on 6x using the old FCKeditor module (6.x-1.3) as well as the Wysiwyg module. I found this thread while looking for solutions. Probably an FCKEditor issue rather than WYSIWYG or FCKeditor module issue?
Comment #3
ron_s CreditAttribution: ron_s commentedAs I said above, this does not happen for me using the old FCKEditor module (5.x-2.2) with FCKEditor 2.6.4. I actually have it running on a live site right now, and I just tested it in Safari 4 to make absolutely sure it works. It does.
Seems to me the issue here is in the Drupal module(s), not with the rich text editor. Maybe the issue is in the FCKEditor module 6.x, and the same issue exists throughout the WYSIWYG module.
Comment #4
sunNote that FCKeditor module 2.x was rewritten, so there might be a difference. However, I don't see how Wysiwyg module could trigger this effect for one input format, but not another, because the general editor setup ("height" in this case) is applied identically to all input formats. Most probably, this means that this bug is triggered by an editor plugin/button that's enabled for your first input format, but not in the other.
Comment #5
JimSmith CreditAttribution: JimSmith commentedI was having similar problem using FCKEditor 2x. Your last comment, @sun, is right on target.
The problem went away for me when I switched from "Use theme CSS" to "Editor default CSS."
Comment #6
sunThanks for reporting back.
This most probably means that your theme applies some crazy styles (position: relative; or height; or whatever) to the body element, and those styles are inherited by the content area of the editor.
Can you add this to the FAQ for Wysiwyg module ?
Comment #7
ron_s CreditAttribution: ron_s commentedSlow down here... this doesn't fix it. I just tested that out and it does not correct the problem at all. And actually, there is absolutely nothing crazy in our CSS theme. In fact, the only difference between our Full HTML theme and our Filtered HTML theme is the background color, yet one works and the other does not.
Tell me, does this look like a crazy body style to you?
Position and height are not defined in any of our CSS styles for the editor. There is something else happening here.
Comment #8
ron_s CreditAttribution: ron_s commentedI have stripped Filtered HTML of all plugins and buttons, have removed every option in "admin/settings/wysiwyg", and I am using the default CSS rather than a customized one. As you can see on the attached picture, the problem still occurs.
My guess is the WYSIWYG module is somehow inheriting CSS from the main page container only in Safari and Chrome. I would expect the CSS for FCKEditor should be completely disconnected from the CSS of the site, but it seems to not be the case.
Comment #9
ron_s CreditAttribution: ron_s commentedDouble post.
Comment #10
ron_s CreditAttribution: ron_s commentedA bit more information -- the text editor sits within a column on our web page. The CSS of the web page defines the column as a 650px wide DIV. If I remove the width from the CSS (of the page, not of the editor), the problem is gone.
Somehow the text editor is being influenced by the CSS of the container in which it sits. This CSS code hasn't changed in over a year, and wasn't an issue in the past.
Comment #11
redpuma CreditAttribution: redpuma commentedI just made the changes to the profile so that it uses default css was set in all profiles. (this is 6x.2.0 + FCK 2.6.4.1) and nothing has changed for me ( Windows + Chrome browser), I still get this problem ron_s describes. No problem in FireFox 3.5
The site uses Aquia Slate , 3 columns and the container the text area is in is 400px wide. I quickly set to Garland (wide container didn't check pixels) and tested problem went away.
Hope that helps.
Comment #12
sunThanks for reporting back. That's exactly what I thought: This is theming issue.
FCKeditor uses these settings by default:
So, to get to a helpful FAQ entry, we should find out, what exactly in theme/CSS triggers this issue.
Comment #13
ron_s CreditAttribution: ron_s commentedSun, I agree this is related to theming, but how is it possible that I am using the exact same version of the editor (2.6.4) and the exact same theme (absolutely no changes to the site design for a long time) yet it works with FCKEditor Module 5.x-2.2, and it doesn't with WYSIWYG?
All things being the same, the two Drupal modules are handling something differently.
Comment #14
sunMost likely, because the editor configuration settings are different? See #12 for Wysiwyg's defaults.
Comment #15
cpelham CreditAttribution: cpelham commentedI have the same issue in Safari using 6.x-2.0 and Acquia Slate. I tried switching to Garland, Minelli, Zen, Bluemarine, and Blueprint and the problem remains in all of those themes.
I tried using
iframe#edit-body___Frame {
width: 300px !important;
height: 500px !important;
}
to override the dimensions, and it does override the dimensions but the edit box still cuts off the text half-way down.
Is there a separate bit of CSS that specifies where the scroll bars are to be placed or how far down the text should be displayed within the iframe?
Comment #16
ron_s CreditAttribution: ron_s commentedThere is a similar post about this on the FCKeditor forums: http://www.fckeditor.net/forums/viewtopic.php?f=6&t=13222. Seems as though some people have created a workaround, but the workaround does not work correctly in all situations.
Of course this still doesn't explain why the editor works fine with the Drupal FCKeditor module 5.x-2.2... :-)
Comment #17
cpelham CreditAttribution: cpelham commentedRegarding the solution linked to in #16 (reprinted below), where do we insert those two code snippets (for them to work within a Drupal 6.x site with WYSIWYG and FCKEditor)?
Comment #18
ron_s CreditAttribution: ron_s commentedIt says right in the message you posted:
and ...
Therefore the first block of code should be placed somewhere so that it loads after the FCKeditor. And the function needs to exist somewhere in a JavaScript file that you have defined for your site.
Comment #19
cpelham CreditAttribution: cpelham commentedThat's really not very helpful. It's not like I've got static html pages to add these into. I've got page.tpl.php. Into which the wysiwyg module inserts the FCK editor code whenever there is a form. I don't want to add this code to every page as that would be inefficient. At the moment I'm using FCK editor only on node edit forms, so then should I install Node From Template module and make a new template for node edit pages and insert the code there? And if so, where in the file would I put this? In the header? What if Panels is overriding the node edit form?
Comment #20
redpuma CreditAttribution: redpuma commentedCould the javascript be called in an if statement?
or a call to a function that does the check.
Comment #21
sunThe second page on that thread is a bit obscured, but contains more follow-ups: http://www.fckeditor.net/forums/viewtopic.php?f=6&t=13222&sid=44979631d8...
Given the amount of people that followed up over there, this seems to be a bug in FCKeditor itself, which only gets triggered under certain circumstances. So this needs to be fixed in the original editor library.
I've searched fckeditor.module's queue for similar issues, but could not find any. Someone should additionally search http://dev.fckeditor.net for existing bug reports (the forum is a forum only).
Due to that, this won't fix. However, keeping this issue open for a while.
Comment #22
cpelham CreditAttribution: cpelham commentedI just searched http://dev.fckeditor.net with various keywords like scrollbar bug safari chrome but did not come up with any references to the problem.
I posted a new bug ticket here:
http://dev.fckeditor.net/ticket/4157
Comment #23
cpelham CreditAttribution: cpelham commentedMy problem within Safari (don't have Chrome) was resolved by replacing the following line about 40 lines from the bottom of the file /FCKEditor/editor/fckeditor.html
if ( FCKBrowserInfo.IsGecko && !FCKBrowserInfo.IsOpera )
to
if ( !FCKBrowserInfo.IsIE && !FCKBrowserInfo.IsOpera )
Comment #24
redpuma CreditAttribution: redpuma commentedJust tested on Window XP + Chrome - Drupal 6.13 Wysiwyg 6x.2.0 + FCK 2.6.4.1 and confirm the errors goes away with the above code (#23).
But have you seen this in Opera? with or without that change in Aquia Slate (narrow cols) or Garland all I get is the FCK toolbar no text area.
Comment #25
cpelham CreditAttribution: cpelham commentedAfter working correctly a few times, I have now started getting a different and much worse error, which leaves me completely unable to edit with FCKeditor or as plain text:
Toolbar set "Wysiwyg" doesn't exist
Sometimes, on reload, this error goes away and the FCKeditor works as it should, and sometimes FCKeditor is drawn correctly, but no node contents are displayed in the edit box. In other words, it's behaving erratically now in Safari.
Comment #26
ron_s CreditAttribution: ron_s commentedcpelham, if you understand the structure of Drupal, you will know there are various template pages (page.tpl.php, node.tpl.php, block.tpl.php, and any others you might create), and template.php. You can add a new function to template.php and load it to page.tpl.php, node.tpl.php, or wherever else you may wish. This should work without issue.
I would recommend using conditional logic (such as,
if (arg(0) == 'node' && arg(1) == 'edit') {
, for example), to control on which pages the javascript is run. Nothing more to it than that.Comment #27
druojajay CreditAttribution: druojajay commentedSubscribe
Comment #28
sunThe official ticket for FCKeditor has been marked as duplicate of http://dev.fckeditor.net/ticket/3053
And that bug report has been marked as fixed, so all you should have to do is updating the FCKeditor library to the latest version.