Xinha and PHPMyEdit

ajh · 2005-02-21 05:51:13

Hi Gogo,

I am the maintainer of the HTMLEdit extension to the PHPMyEdit (PME) project (http://platon.sk) and have spent the last three weeks struggling with a problem with HTMLArea and PME. I am hoping that Xinha may be able to help me with getting to the bottom of it. PME has the capability to display and hide sets of fields based on the "tabs" that they are in. This is done by enclosing each block of fields in <DIV> tags which are displayed or hidden as appropriate using Javascript. The problem I have is that if one of the fields in one of these divisions is an HTMLArea field, it works fine when it is initially generated, however as soon as the division is hidden (using display:none) and then redisplayed (using display:block), the HTMLArea field blows up - it displays but you cannot type into it. This is not a problem using IE.

Are you able to throw any light on this behaviour? It's difficult to see whether it is a browser bug or an HTMLArea problem, or just something that is different between browsers.

I have simple html script which does a great job of displaying the problem if you have time to have a look at it. I have already noticed a number of people on this forum who I know use this PME extension, so it would be great to get it fixed.

Many thanks in advance,

Adam

ajh · 2005-02-21 05:57:18

BTW - just tried both Xinha-latest and Xinha-nightly, the problem is still there with FF. Works fine with IE.

gogo · 2005-02-21 05:58:25

It's a known bug in Gecko (I reported it a while ago).

In Xinha, what you want to do is issue a deactivateEditor() when (before) hiding and actiateEditor() when restoring (after showing), these are methods of the editor object you create. In HTMLArea you'll have more of a problem.

Basically, any time you are changing the style, be it directly, or inherited, of the iframe containing the editor, the safe way is to deactivate, change the style, activate, otherwise Moz will throw a hissy fit more often than not.

ajh · 2005-02-21 06:00:47

Thank you!!! I came to the conclusion that I was going to have to write something like that. I'll give that a go and see what happens.

ajh · 2005-02-21 06:50:29

YES!!! It worked. Now I need to recommend that all users of the PME HTMLArea extension move to Xinha!

phirschybar · 2005-02-21 19:09:05

alrighht ajh... you made it over here! Looking forward to seeing what ya got.

ajh · 2005-02-23 06:26:38

Firstly - to all you PME fans, the latest Xinha-ised version of the new htmlcal extension is posted at Platon.SK on Bug Report 205.

However - I still have a problem that I hope that someone on this forum can help me with. I am getting an intermittent problem where the browser (normally IE, although I think that I've seen it in FF) doesn't draw the HTMLArea fields - they're left as normal textareas. However doing a simple refresh of the page will fix the problem and display them. So it looks like some kind of timing problem (if that's possible). Has anyone seen anything like this before? I'm pretty sure my code is correct as it does work sometimes with no problems.

Any ideas anyone?

anzenews · 2005-02-23 07:31:30

I have seen this with Htmlarea 2.03 from time to time - not always and not on all machines. I played around with 'defer' and I succeeded in fixing a problem, but can't be more specific than that - it was a long time ago.

Is it possible that your JS function (the ones that converts textarea to htmlarea) are called before textareas exist?

I do not have these problems but this could be the reason (race condition). The way I do it:

I always put this at the end of the document (just before '</body>') :
<script type="text/javascript">
HTMLArea.init();
</script>

This calls the function that is registered under HTMLArea.onload (like this: HTMLArea.onload=initEditors; ).

Since my function (initEditors) is called just before </body> all of the textareas are already there - so you don't get race conditions.

Defer is not really reliable - it just tells the browser that it MAY defer execution of JS if it wishes. But no promises are made (and it depends from case to case how much the scripts are defered).

Hope it helps.

Anze

ajh · 2005-02-23 07:37:23

All of the HTMLArea fields are generated just before the end of the BODY as well, so I don't think that I can do anything there. I'll try defer.

Also - side question...do you actually need to call HTMLArea.init? At the moment I am creating a new HTMLArea object and then using the generate() method on it - that seems to work fine.

UPDATE:

'defer' made no difference, but what was odd was that I started debugging by putting in an alert before the routine that generates the HTMLAreas - and the problem has gone away. So it does seem to be a timing issue. Bizarre!!

Last edited by ajh (2005-02-23 07:48:20)

anzenews · 2005-02-23 11:24:37

Hey, now I have the same problem... The client reported that she can't find the buttons.

It works fine in FireFox, but not in IE on Windows. And refresh doesn't help. I will add defer, but apart from that - maybe a timer? Until it is solved properly that is... I will let you know if it helps.

gogo · 2005-02-27 01:13:52

Hmm. All I can say is that I've never seen this problem, that said I use FFox more than IE so perhaps I've been lucky. I can't really think why it wouldn't work.

Are any javascript errors thrown on the page when it doesn't load up? Perhaps one of those who are seeing it could install the MS Script debugger?

KaplanDigital · 2005-04-04 21:04:32

gogo wrote:

It's a known bug in Gecko (I reported it a while ago).
In Xinha, what you want to do is issue a deactivateEditor() when (before) hiding and actiateEditor() when restoring (after showing), these are methods of the editor object you create. In HTMLArea you'll have more of a problem.
Basically, any time you are changing the style, be it directly, or inherited, of the iframe containing the editor, the safe way is to deactivate, change the style, activate, otherwise Moz will throw a hissy fit more often than not.

How would you use the functions deactivateEditor and activateEditor in a plugin?
It cant be e.deactivateEditor(); as I tried it and it did not work.
I am modding the fullscreen plugin to work with the cms etomite and have tried this code to no avail (AFTER LINE 63 IN FULL-SCREEN.JS)

    deactivateEditor();
    var node = document.getElementById("tadiv");
    node.className = "sectionBody";
    actiateEditor();

Lines 2 and 3 WORK with no problems when lines 1 and 4 are removed!!!

-KD

gogo · 2005-04-05 00:22:04

How would you use the functions deactivateEditor and activateEditor in a plugin?
It cant be e.deactivateEditor(); as I tried it and it did not work.

They are methods of the editor object, if you have the editor object in question referenced by e then that is correct. If you have it referenced as foobar, then foobar.activateEditor() is correct.

What version are you editng? Line 63 in fullscreen of the current nightly precedes the full screen method definition (which is prototyped into the editor object, so within that method you could use this to reference the editor of course).

Xinha Discussion Forum

Announcement

#1 2005-02-21 05:51:13

Xinha and PHPMyEdit

#2 2005-02-21 05:57:18

Re: Xinha and PHPMyEdit

#3 2005-02-21 05:58:25

Re: Xinha and PHPMyEdit

#4 2005-02-21 06:00:47

Re: Xinha and PHPMyEdit

#5 2005-02-21 06:50:29

Re: Xinha and PHPMyEdit

#6 2005-02-21 19:09:05

Re: Xinha and PHPMyEdit

#7 2005-02-23 06:26:38

Re: Xinha and PHPMyEdit

#8 2005-02-23 07:31:30

Re: Xinha and PHPMyEdit

#9 2005-02-23 07:37:23

Re: Xinha and PHPMyEdit

#10 2005-02-23 11:24:37

Re: Xinha and PHPMyEdit

#11 2005-02-27 01:13:52

Re: Xinha and PHPMyEdit

#12 2005-04-04 21:04:32

Re: Xinha and PHPMyEdit

#13 2005-04-05 00:22:04

Re: Xinha and PHPMyEdit

Board footer