TYPO3 Core

What content type do you edit when the RTEhtmlarea doesn't load correctly? Regular content elements (tt_content), record stuff e.g. with IRRE, or anything else? Especially for the IRRE context there were some problems in TYPO3 4.1.1 that have been fixed in TYPO3 4.1.2.

I am editing ordinary text content elements in tt_content. The editor never comes up and the "The editor is loading, please wait" is never disappearing.

i had the same problem some time ago. The problem ist or was the CSS-file, if he can't loaded, he will not show up the rte.

Yes, it seems the stylesheet is not loading, according to the error message. But what is the problem that prevent him from loading the stylesheet, since it is loading without any problem on other PC's. What kind of settings on a PC could give problems loading a stylesheet?

I am expenriencing the same (similar) effect with Opera (9.23 and before) and Firefox (2.0.0.7 and before) since some time.
The only editor that works is IE (which by the way I don't want to use, but this is another story)

Are you still experiencing problems on this PC?

Are the stylesheets very big? Are the communications with the server especially slow from that PC?

No, I have not found any solution to the problem. That single PC does not load the editor, it is just hanging in an eternal loop.

The PC is connected via a wireless network, but the speed seems to be normal.

Stylesheet is not big and contains only the following:
/* bahai.no CSS-File for RTE-Config /
/ Gunnar Jonsson, 3.2.2007 */
.normal {
text-align: left;
font-style: normal;
font-weight: normal;
text-indent: 0%;
}
.sitat_hellig {
text-align: left;
font-style: normal;
font-weight: bold;
text-indent: 10%;
}
.sitat_diverse {
text-align: left;
font-style: normal;
font-weight: normal;
text-indent: 10%;
}
.sitatkilde {
text-align: right;
font-style: italic;
font-weight: normal;
text-indent: 0%;
}
.overskrift_nivå_2 {
text-align: left;
font-style: italic;
font-weight: bold;
text-indent: 0%;
padding-top: 20px;
}
.overskrift_nivå_3 {
text-align: left;
font-style: normal;
font-weight: bold;
text-indent: 0%;
padding-top: 10px;
}
.rød_fet_skrift {
font-style: normal;
font-weight: bold;
color: red;
}
.rød_normal_skrift {
font-style: normal;
font-weight: normal;
color: red;
}

For me the problem appears in the BE Content Editing.

Maybe a hint, which caused me also some problems in the FE is a possible problem with the
"If-Modified-Since" Pragma.
regardsless of a "no-cache" Pragma set on the previous output the response is always a
"HTTP/1.1 304 Not Modified"

This problem arose for me with some pages which where not updated. Which is especially a pain if this are the login-pages. The user always gets the stored page, which possiblby was a failure message.

But this seems now to me to be a similar problem here.

As I alread said, this happens since some time with Opera as well as FF. FF worked some time ago with no problem. Only IE now works properly, because IE does not send the If-Modified.

I attach the trace of the communication between the browser and the server after hitting the edit-button for a page content in the backend. One file with the complete trace for Opera, the second with the same using IE (here I cut the end as there was just only a further bunch of GIF's downloaded).

I think we are discussing two different issues here.

Kurt,

Would you please open a distinct issue for the problem you are reporting.

Thanks.

Stanislas,

I don't think so.
As I stated earlier, I do have the identical problem as Gunnar.
So I have traced the communication and this clearly shows that there is difference between the browsers opera and FF vs. IE.
IE is not sending the "If-Modified" and gets the css-files sent, while Opera and FF sends the "If-Modified" and don't get the css-files. Which is in line with Dirks and Gunnars comments above.

But I only wanted to help solving a problem.

Regards.

Greetings, everyone.

Just wanted to chime in and relate that I have much of the same problem as Johnsson. It seems the init script (HTMLArea::initIframe) of the RTE loops ad infinitum. My problem varies reliably with browser and use of proxy (Oracle portal).

IE (6.0) & proxy: RTE doesn't load (but textarea available): JS errors: HTMLArea and TBE_EDITOR undefined
IE & no proxy: RTE works as a dream.

FF (2.0.0.8) & proxy: RTE doesn't load ("Editor is being loaded"). Error messages loop.
FF & no proxy: RTE works as a dream (recovers from "Failed attempt at loading stylesheets").

According to the error message the error is "A parameter or an operation is not supported by the underlying object" in line 1100 of an rtehtmlarea javascript file. The line is:

if (HTMLArea.is_gecko) try { rules = doc.styleSheets[rule].cssRules; } catch(e) { stylesAreLoaded = false; errorText = e; }

This leads me to suspect something about HTMLArea is in error, but not being a JS guru I'd hesitate to be too certain. What's surprising is that the error, which at least is reported as a JS problem varies with connection type. Also, FF actually experiences the problem but is able to recover. It seems at my first glance that the recover algorithm is simply setting window.setTimeout.

I'll look more into this problem, and maybe some knowledgeable person gets a revelation from this report. I attach a more verbose matrix of errors as well.

@Theodor: This exception is normal. The RTE needs to make sure that the stylesheets are loaded before completing its initialization. The only way to do so is to try to access the stylesheet objects. If the stylesheets are not yet loaded, they cannot be accessed and the exception is raised... and catched. The RTE retries until the stylesheets are fully loaded. The number of retries may vary with the speed of the connection, the size of the css files, and the number of @import (and depth of nesting) in the stylesheets.

A never ending loop means that the stylesheets are never loaded for some reason.

@Kurt: I don't understand how the problem reported by Gunnar would be related to "If-Modified" if his installation is using only IE and the problem is showing up on onle one PC.

@Gunnar:
1. Are you using mod_gzip on the server?
2. Is the particular problematic PC behind a proxy?
3. Have you tried to disable the firewall on this PC (just for testing purpose)?

@all review,

Can some of you try to check the communication the way I did it. I used CommView from Tamosoft (http://www.tamos.com) which you can downlooad for a free 30 days trial.
Check if the css-files are transmitted and what the difference in the working an non-working situations are.

@Stanislas
Why do I think that there is a relation: I have just found on another - non html-area related - problem with Typo3 found that since some time ago there is a problem with the no-cache:Pragma and the If-Modified:Pragma. When the IF-Modified Pragma is sent by the browser (which is the case with my Opera and FF), there is a 304-No Change -Respone from the server, REGARDLESS of the previous no-cache:Pragma.
And the same happens with here. The css-file is not downloaded because of the 304, therefore the script seems to wait indefinitely.

If you can check my files above, the difference can easily be seen.

I would not bet that my tip is the source of the problem, but might be a hint for the reason.

To Stanislas
1. Are you using mod_gzip on the server?
- mod_gzip is not included in "loaded modules" in phpinfo.php

2. Is the particular problematic PC behind a proxy?
- No it is not behind a proxy. And I have another PC which is behind a proxy but I have no problem with the editor on that PC.

3. Have you tried to disable the firewall on this PC (just for testing purpose)?
- I will test that as soon as I could lay hands on that PC.

@Gunnar:
You may also want to try to set your site as a trusted site in IE Internet Options.

I have done some more testing.

The first thing I tried, was to make a hack which sent the base URL to the init script from the php logic on the server, so that "Iframe baseURL" could be the same as where the browser tried to get the css files from. I got it to work, but it didn't help.

So I tried the http header route, hunting for 304 Not modified headers, which, alas, didn't help either. But I found a few .. well.. findings.

As for the effect of If-modified-headers, I tried this with the replay-function of the Live HTTP Headers plugin for FF. It works as expected and pointed out by Karl: with the headers the server responds with the 304-header and no file.

That is, if the browser requests the file. Which doesn't happen!

The other thing finding is that even when the 304-header is sent it still doesn't hinder the editor from opening. In my environment, there is one reliable determinant as to wheter the editor opens or not, and that is: if the page is served via the proxy the script loops (more on that in a sec), and if it is served directly it works like a dream. Which, of course, is nonsense - there's got to be some other reason, of course.

The looping doesn't actually cause the script to request the stylesheets anew, it seems to just wait for the browser to accept them.

The script actually fetches the css-files if the local browsercache is empty, complete with a 200 OK from the server (both proxy and actual server). Still, only when the connection goes directly to the actually serving server will the editor open.

If the local cache is populated from an earlier visit, the browser doesn't ask for three of the four files which seem related to htmlarea (and of course it doesn't get no reply, neither 200 og 304), It only asks for htmlarea.css, with the reply 304. (Htmlarea.css is set as "editor skin" in HTMLArea::init, the three others are set in initIframe, FWIW) Still, the browser that connects directly is able to open the editor, the browser visiting via the proxy is not.

I have not compared these findings in FF with IE, as they don't seem to be browser-spesific. (Even if FF is able to replace the textarea with "Please wait..:" and IE keeps the textarea, they both are not able to initialize the RTE when connected through the proxy/portal-thingy).

In conclusion:

Gunnars failing installation might be stuck in the position of having to go through a proxy of some kind, at least the symptoms I read looks a lot like mine. Of course, my problem is that the proxy is on the server side, and people are supposed to connect via the portal and not directly to the actual server, so the workaround has to die.

It also seems that initIframe is the point of surfacing of a problem: why does it not even ask for the stylesheets when the connection is via server and the browser cache is populated? And why is it not able to init the editor when it receives the stylesheets over the wire - and the wire runs via the proxy?

Whew,, Man, this took a while to write and conduct. I hope it's legible... And even more that someone gets a bright idea.

Pax.

Is this still an issue with TYPO3 4.3?

Just a quick feedback: Yes, still an issue in my setup.

Actually, I have just before this weekend experienced a seemingly related issue in the frontend, where AJAX (eID) calls works only when the data is called with the same referer as the request (that is, it doesn't work when the AJAX call from www.customersite is adressed to webserver.customersite, only from a page on webserver.customersite to webserver.customersite). CheckReferer is false, of course (though I'm not sure if eID scripts checks referer at all?).

Anyway: upgrading as not solved this issue for me. I quess I'll have to dive into this again soon, as this AJAX issue is not possible to work around. I'll keep you all updated if there are any developments.

If you have a chance, please try the upcoming TYPO3 4.4beta to be released this week. The RTE loading process has been much modified and all absolute url's have been removed.

As for the stylesheets, there is not other way (except in Opera) to ensure that they will be accessible for processing by the RTE scripts.

The problem with the RTE seems to be solved with 4.4beta1. Haven't done extensive testing, but it does load in my setup. Still running the beta, will report if there is more to say.