Opened 16 years ago

Closed 15 years ago

#93 closed defect (fixed)

contents randomly disappear

Reported by: mack@… Owned by: gogo
Priority: normal Milestone: Version 1.0
Component: Xinha Core Version: trunk
Severity: critical Keywords:


when there's an img tag in the contents of the textarea upon page load, they will show for a second and then just randomly disappear. it behaves otherwise normally, as if nothing was ever in there. and it only happens sometimes (but once it starts happening, it tends to keep happening)

Change History (13)

comment:1 Changed 16 years ago by mack@…

also, it seems that once this happens, everything is screwed. clicking on just about anything in the toolbar throws a cryptic exception, and reloading the page just gives you the same broken situation. the only way to 'fix' it is to restart the browser -- and then it will only work one time. reload again and everything breaks. this is on firefox by the way.

comment:2 Changed 16 years ago by riftdesign

In Firefox, I have found that duplicating a tab will 'fix' it, but it definitely isn't a fix and it is annoying.

comment:3 Changed 16 years ago by mack@…

it seems i've found a stopgap solution.

in htmlarea.js, in the function HTMLArea.prototype.initIframe, at line 1506 or so, there is this:

setTimeout(function() {


}, 250);

Simply comment it all out (or just the middle line, really), and that solves the problem. I'm not quite sure what the "real" problem is, but this is good enough for me.

comment:4 Changed 16 years ago by Niko <ns@…>

This fix does work for mee too.
does it have any side-effects?
(i mean, there must be a reason why updateToolbar is called)

comment:5 Changed 15 years ago by guillaumed

In any case such timeout function is too dependant of performance.. 250 is good today but tomorrow.. So it should be changed...

comment:6 Changed 15 years ago by gogo

Hmm, interesting. I see why you commented that out now in changeset:64 Guillaume (but next time please make a note in the commit log for any changes so we can cross reference).

The only side-effect of this is that the toolbar won't start updating until some event has happened in the editor (keypress etc). I guess that's a reasonable thing? I'm happy to leave it commented out for now and we'll see if anybody complains.

comment:7 Changed 15 years ago by guillaumed

No I was trying other interfaces to update tollbar, based on event and I didn't realize that it was not reset...
If you don't mind I prefer rollover this mistake until I will propose something better..

comment:8 Changed 15 years ago by gogo

I don't think it will be a problem, and if simply removing that initial updateToolbar stops the "everything goes blank" problem which is very frustrating (I find that restarting Firefox usually fixes it for a while) then I think that's the way forward at least for the time being.

comment:11 Changed 15 years ago by gogo

guillaume: in your opinion is this fixed now? If it is, you can close it.

comment:12 Changed 15 years ago by gogo

  • Milestone set to Version 1.0
  • Version set to trunk

comment:13 Changed 15 years ago by guillaumed

  • Resolution set to fixed
  • Status changed from new to closed

No other remarks so I think it can be considered close

Note: See TracTickets for help on using tickets.