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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ron_s’s picture

Version: 6.x-2.0 » 5.x-2.0

Sorry, this is documented for 5.x, not 6.x.

redpuma’s picture

I'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?

ron_s’s picture

As 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.

sun’s picture

Status: Active » Postponed (maintainer needs more info)

Note 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.

JimSmith’s picture

I 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."

sun’s picture

Category: bug » support
Status: Postponed (maintainer needs more info) » Fixed

Thanks 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 ?

ron_s’s picture

Category: support » bug
Status: Fixed » Postponed (maintainer needs more info)

Slow 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?

body {font-family:Arial, Helvetica, sans-serif; font-size:12px; line-height:1.3em; text-indent:0; padding:0; margin:3px; text-align:left; background-color:#EEF2F7; color:#222; background-image:none; }

Position and height are not defined in any of our CSS styles for the editor. There is something else happening here.

ron_s’s picture

I 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.

ron_s’s picture

Double post.

ron_s’s picture

A 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.

redpuma’s picture

I 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.

sun’s picture

Thanks for reporting back. That's exactly what I thought: This is theming issue.

FCKeditor uses these settings by default:

    'Width' => '100%',
    'Height' => 420,

So, to get to a helpful FAQ entry, we should find out, what exactly in theme/CSS triggers this issue.

ron_s’s picture

Thanks for reporting back. That's exactly what I thought: This is theming issue.

Sun, 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.

sun’s picture

Most likely, because the editor configuration settings are different? See #12 for Wysiwyg's defaults.

cpelham’s picture

FileSize
35.16 KB

I 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?

ron_s’s picture

There 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... :-)

cpelham’s picture

Regarding 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)?

Re: Vertical scrollbar height in Safari
by aaj on Mon Jun 15, 2009 11:08 pm

I've also noticed that problem with the recently-released Safari 4 and the newest version of Google Chrome and was able to find a (somewhat ugly) workaround.

From the context of the page including the FCK editor instance, you can run the following JavaScript:

<script>
  document.getElementById('editor___Frame').contentDocument.getElementById('xEditingArea').style.height = '100.1%';
  setTimeout(function() { 
    document.getElementById('editor___Frame').contentDocument.getElementById('xEditingArea').style.height = '100%'
  }, 100); 
</script>

This code should run after the FCK editor has finished loading. To execute it automatically after FCK is initialized, define the following function:

<script>
function FCKeditor_OnComplete( editorInstance ) {
      var fck_iframe = document.getElementById('editor___Frame');
      var fck_editing_area = fck_iframe.contentDocument.getElementById('xEditingArea');
      fck_editing_area.style.height = '100.1%';
      setTimeout(function() {fck_editing_area.style.height = '100%'}, 100); 
}
</script>

This works for our site with a single FCK instance, but we haven't extensively tested it -- depending on your installation, it's possible that the iframe ID or the timeout might have to be adjusted. But until someone comes up with a proper solution, the workaround might hopefully be of use to some people.

ron_s’s picture

It says right in the message you posted:

From the context of the page including the FCK editor instance, you can run the following JavaScript:

and ...

This code should run after the FCK editor has finished loading. To execute it automatically after FCK is initialized, define the following function:

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.

cpelham’s picture

That'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?

redpuma’s picture

Could the javascript be called in an if statement?

or a call to a function that does the check.

sun’s picture

Title: Filtered HTML textarea cut in half when using Google Chrome or Safari » FCKeditor: Textarea cut in half on Google Chrome or Safari
Component: Code » Editor - FCKeditor
Category: bug » support

The 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.

cpelham’s picture

I 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

cpelham’s picture

My 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 )

redpuma’s picture

Just 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.

cpelham’s picture

After 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.

ron_s’s picture

That'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.

cpelham, 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.

druojajay’s picture

Subscribe

sun’s picture

Status: Postponed (maintainer needs more info) » Fixed

The 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.