TYPO3 Core

Does the FE extension set $this->RTEObj->RTEdivStyle?

No. $this->RTEObj->RTEdivStyle is set by in tx_rtehtmlarea_pi2 and is correctly transmitted to the RTE.
The height value of the code generated by the drawRTE method is OK, i.e. the styles associated with the div (' editorwrap") and the textarea.

Using firebug, the style associated with the iframe tag generated by the js code has a height attribute equal to "0px". When I change manually this value with firebug, of course the content of the RTE is correctly displayed.

Assuming that $RTEHeight = 380px in tx_rtehtmlarea_pi2.
In the class HTMLArea.Framework (htmlarea.js) in the method getInnerHeight() I get :
this.getSize().height = 538
this.toolbar.getHeight() = 135
this.statusBar.getHeight() = 403

therefore, the value returned by getInnerHeight() is negative (-5)

When I display the RTE item in the BE, the RTE is correctly displayed. The values are:
this.getSize().height = 380
this.toolbar.getHeight() = 109
this.statusBar.getHeight() = 22

and the returned value is positive (244).

I wonder why I can't reproduce this issue.

Signout from the BE.

Look at the source of the FE page.

What values are assigned to
RTEarea[editornumber].RTEHeightOverride
and
RTEarea[editornumber].resizable ?

RTEarea[editornumber].RTEHeightOverride = "0";
RTEarea[editornumber].resizable = false;

Making the RTE resizable by setting rteResize to 1 in the parameter $thisConfig solves the problem.

The RTE in the FE seems to be running correctly only if it is resizable.

The height of the statusbar looks strange. Maybe a css issue...

What skin do you use for the RTE?

Do you specify some height for textareas in the stylesheets of your FE?

Do you still have the same issue if you hide the statusbar?

skin -> t3skin
No CSS rules for textarea
Same behaviour when showStatusBar is set to 0.

I am unable to reproduce this issue.

The reported height of the statusbar is obviously wrong.

Is there content in the RTE when it is loaded? Could you upload a screenshot of the RTE as it is drawn on the page?

Two files uploaded. rteResizeEqual0.gif is the display obtained when rteResize = 0 and rteResizeEqual1.gif is the display when rteResize = 1.

In the first case, nothing is displayed because in the style attribute of the iframe tag generated by the js code, the height is set to 0px. In the second case, the display is correct, the window is resizable.

Using rteResize =1 solves my problem but I do not understand why in the BE the RTE is not resizable and displays correctly the content but not in the FE.

Anyway, Stanislas, thank you for your help.

hum... Very strange. The editing area is not collapsed, just not visible...

Does your extension hide the RTE at any point?

Does it work correctly in Chrome or Safari?

My extension does not hide anything.

I've downloaded three new screenshoots for (IE, chrome and safari) when rteResize = 0.

IE -> extension works but the size is bigger than expected.
Chrome -> extension works correctly.
Safari -> same behaviour as with Firefox, the content is not displayed.

I have the same problem with cal_base 1.5.1 and Typo3 4.5.
In FE the iframe has height and width of 0px.
There was a mention of rteresize. Where could i enable that ?
Actually: I can resize the window with firefox and openSUSE.
When I do the iframe appears - it was invisible before.

I can't resize with firefox on Apple. Safari on the same
System ( Max OS X 10.7.5 ) also doesn't show the resize
Symbol.

So I don't know if resize is enabled.

Is there maybe a javscript broken which resizes the iframe ?

regards, C. Holtermann

Hi Christoph and others.

I looked the resizable setting myself. You can set it in page TS with
RTE.default.FE.rteResize = 1

Its not really a very good solution though, since the height initially is still 0 px and you
have to make your users drag the iframe window bigger before they can use it.

Is there no real fix for this?

I'm using TYPO3 4.5.20 and the FE rte is used by cal 1.5.1

When i put an alert() somewhere in the javascript the editor resizes successfully. It could be for example
the first line of this function:
/* * Resize the framework to its initial size
*/
resizeFramework: function (width, height) {
alert("XYZ");

I don't know how to make this a workaround for that would need a function that acts like alert without the user needing to push the button.
Or better find out why waiting helps. Seemingly a function is executed to early when the initialisation has not taken place properly.

BTW: Resizing as suggested does not always work.

I found a way to make it work. I added the marked lines in function InitializeIframe. Before Initialization it checks if
the frameworks width has already been set. I don't know if this fits in the existing logic or if it's the right way to do
it. It just works for me - as far as I could see until now. I will tell if it doesn't.

initializeIframe: function () {
var iframe = this.getEl().dom;
// All browsers
if (!iframe || (!iframe.contentWindow && !iframe.contentDocument)) {
this.initializeIframe.defer(50, this);
// All except WebKit
} else if (iframe.contentWindow && !Ext.isWebKit && (!iframe.contentWindow.document || !iframe.contentWindow.document.documentElement)) {
this.initializeIframe.defer(50, this);
// WebKit
} else if (Ext.isWebKit && (!iframe.contentDocument.documentElement || !iframe.contentDocument.body)) {
this.initializeIframe.defer(50, this);

} else if (this.ownerCt.getInnerWidth()==0) {
this.initializeIframe.defer(50, this);

In a testcase this made the event loop about 8 times.

My suggestion doesn't really solve the issue...

Links in the text are not being correctly rendered. Only the link destination is being shown as text. The link text is missing. No a-tag is written.

When i took my patch away and looked at the original situation i found error messages like

TypeError: computedStyle is null
http://www.jungmedizinerforum.org/typo3/sysext/rtehtmlarea/htmlarea/plugins/TextIndicator/text-indicator.js?1362647826
Line 111

On other events (using cal base) the error occured on other places always with computedstyle being null.

As the errors differ and my suggestion was timing dependent it may be a question of how fast different tasks are being executed...

The computedstyle error may be about visibility in firefox 19.0.2 for OpenSuse 12.2 ( which i use - no such error in chrome )
[ Some relation to this ? http://www.sencha.com/forum/showthread.php?132187-Issue-with-the-computed-style-on-hidden-elements-using-Firefox-and-Ext-JS-4 ]

I think the issue with the links is something different. I again believe in my solution ;-)