Potential solution of designMode = 'on' problems in Gecko.

Yermo · 2005-05-17 22:43:29

So I'm running into the infamous random "designMode='on'" exception. Interestingly in my case if I disabled EnterParagraphs the exception goes away. (This is with my tweaked unified backend).

So I did some googling and came across this interesting tidbit:

https://bugzilla.mozilla.org/show_bug.cgi?id=207842

At the bottom there is an intriguing suggestion:

------- Additional Comment #11 From Derek Davenport 2005-03-31 10:05 PDT [reply] -------

I've found a similar problem that may or may not be related.
On this page
http://derekdev.com/mozilla/iframenoworky.html
An iframe is created and added to the document and then has its designMode
turned on. The designMode stays on until the script stops executing, then it
turns off. Click the button to see that it is indeed off.

My workaround was this
http://derekdev.com/mozilla/iframeworky.html
The iframe turns itself on after it's loaded.

-------------------------------------------------------

So I patched HTMLArea.prototype.generate with the following:

if ( HTMLArea.is_gecko )
  {

  // need to get a var into the closure below.

  editor.isGenerated = false;

  this._iframe.addEventListener("load", 
    function(e)
      {
      if ( !editor.isGenerated )
        {
        editor.isGenerated = true;
        editor.initIframe();
        }
      return true;
      }, 
   false);
  }

instead of using:

setTimeout(function() { editor.initIframe()}, 50);

Interestingly there is quite a delay (several seconds) between the time the textarea shows up and the time the editor displays in situations where the exception would have occurred.

Kill the browser, restart it and the delay goes away for a while.

At least in my testing here, this fixes the persistent exceptions I've been getting on designMode = "on". As indicated in bugzilla this is a known bug in the gecko engine.

I don't know if it's "right" but it does seem to work at least with limited testing.

gogo · 2005-05-17 23:06:28

Interesting (and a much better way of doing it BTW). I wonder if the delay is due to the src we are setting on the iframe. I have found that recently (last few months) my F/fox installs have been having trouble with local connections, they just get slower, and slower, and slower. Restart the fox and it's quick again for a while. It's not anythign to do with Xinha, this is totally without Xinha even in the picture.

I havn't been able to find any relevant bug reports about it though so I thought it was probably just me.

gogo · 2005-05-17 23:10:28

PS: What's the purpose of editor.isGenerated ? Shouldn't

  if ( HTMLArea.is_gecko )
  {
    this._iframe.addEventListener("load",
      function(e)
      {
        editor.initIframe();
        return true;
      },
     false);
  }

do the job?

Yermo · 2005-05-18 00:07:59

It was endless looping on me and I couldn't figure out why. It looked like every time it went to refresh that it triggered the event again

gogo says: .... argh, what the hell happened, I replied to this message and instead it overwrote it! Sorry about that yermo.

Last edited by Yermo (2005-05-18 00:08:28)

Yermo · 2005-05-18 00:09:42

gogo wrote:

Interesting (and a much better way of doing it BTW). I wonder if the delay is due to the src we are setting on the iframe. I have found that recently (last few months) my F/fox installs have been having trouble with local connections, they just get slower, and slower, and slower. Restart the fox and it's quick again for a while. It's not anythign to do with Xinha, this is totally without Xinha even in the picture.
I havn't been able to find any relevant bug reports about it though so I thought it was probably just me.

Hmm. No it's not just you. I've seen the same kind of thing over here but hadn't narrowed it down to the network. I just notice over time firefox gets slower and slower especially with heavy javascript use. I had thought it was because of some threads racing or some such ... but hadn't delved into it.

guillaumed · 2005-05-18 02:27:25

gogo wrote:

I wonder if the delay is due to the src we are setting on the iframe.

This seems to be reasonable with the the ticket 237 with the design setted before opening the document, I found info on https://bugzilla.mozilla.org/show_bug.cgi?id=283897

gogo · 2005-05-18 05:52:25

Lets try that reply again..

It was endless looping on me and I couldn't figure out why. It looked like every time it went to refresh that it triggered the event again

Hmm, well, I don't know. I would have expected it to fire once when the document (about:blank) is loaded. But I guess it may fire again when we do doc.close() because essentially we have replaced the document (illustrated by the insertion into the history list) - of course whether that's an intended behaviour or a bug related to the history insertion I couldn't say.

removeEventListener should work, but you may not be able to do that from within the event listener itself as I loosly recall. So perhaps just setting the boolean is the best way around it.

Yermo · 2005-05-18 13:52:54

gogo wrote:

Lets try that reply again..
It was endless looping on me and I couldn't figure out why. It looked like every time it went to refresh that it triggered the event again
Hmm, well, I don't know. I would have expected it to fire once when the document (about:blank) is loaded. But I guess it may fire again when we do doc.close()

Verified. Removing the boolean and doing an "alert("before doc.close");" before the doc.close and another alert "after doc.close" yields endless before doc.close() alerts .. effectively endless recursion.

gogo wrote:

because essentially we have replaced the document (illustrated by the insertion into the history list) - of course whether that's an intended behaviour or a bug related to the history insertion I couldn't say.
removeEventListener should work, but you may not be able to do that from within the event listener itself as I loosly recall. So perhaps just setting the boolean is the best way around it.

There doesn't seem to be a way around it; and luckily the event only gets called twice (once on about:blank and once on doc.close() so it's not as bad as I had originally thought.)

gogo · 2005-05-19 02:06:27

I'm not sure, but I think you have a race condition in your new code, currently I believe the sequence is...

1. create iframe
2. set iframe.src
3. ... some stuff
4. add onload event to iframe

what happens if the iframe finishes loading while step 3 is happening? You might think it simply a matter of moving the event attachment prior to the iframe src, but that could mean that the initIframe is attempted before the rest of generate is finished?

gogo · 2005-05-19 02:11:48

I wonder if we even need to set the src in the first place. If we droped that then the iframe would perhaps be ready to go as soon as we create it and we could then go straight into initIframe from the tail of generate, no need for timeouts or events.

I guess mish must have put it there for some reason though, so perhaps it just doesn't work without some src.

Yermo · 2005-05-19 02:35:25

gogo wrote:

I'm not sure, but I think you have a race condition in your new code, currently I believe the sequence is...
1. create iframe
2. set iframe.src
3. ... some stuff
4. add onload event to iframe
what happens if the iframe finishes loading while step 3 is happening? You might think it simply a matter of moving the event attachment prior to the iframe src, but that could mean that the initIframe is attempted before the rest of generate is finished?

I do believe you have a point there ...

Yermo · 2005-05-19 02:40:47

gogo wrote:

I wonder if we even need to set the src in the first place. If we droped that then the iframe would perhaps be ready to go as soon as we create it and we could then go straight into initIframe from the tail of generate, no need for timeouts or events.
I guess mish must have put it there for some reason though, so perhaps it just doesn't work without some src.

Hmm. If I read the mozilla bug report right then we have to have some contents in the iframe before being able to set designMode on but I may have misread that; something about a body tag being necessary.

I'll have to experiment with it to see.

Is there any reason why we can't move the iframe.src = ... down to after adding the event because you're right, it looks like a race condition.

For that matter how does the panel code work. Is that a race condition as well? Does the iframe.src get loaded "in the background"?

Hmmmm.

Yermo · 2005-05-19 03:22:47

gogo wrote:

I'm not sure, but I think you have a race condition in your new code, currently I believe the sequence is...
1. create iframe
2. set iframe.src
3. ... some stuff
4. add onload event to iframe
what happens if the iframe finishes loading while step 3 is happening? You might think it simply a matter of moving the event attachment prior to the iframe src, but that could mean that the initIframe is attempted before the rest of generate is finished?

I've done some testing. Based on the way the code reads you would expect it to be a race condition but no matter how much code I put between the iframe.src = and the addEventListener (in terms of a loop printing out messages to another window for example) I can't get it to fail. (This is in firefox. I haven't tested it yet in MSIE although my initial tests worked each time).

It seems like either there's some side-effect of how the multithreading works that the onLoad event is cached somehow .. might be a side-effect of how addEventListener works. I'll have to test it without debugging messages, but if anything you would expect the trace messages to slow everything down allowing the race condition to occur.

There's something I don't understand.

But it clearly works, at least in these test cases. I agree it's not "right" yet. We'd have to do some re-engineering to make it "right".

We'll have to keep an eye on it to see if any reports of brokenness arise.

gogo · 2005-05-19 03:25:37

For that matter how does the panel code work. Is that a race condition as well? Does the iframe.src get loaded "in the background"?

What part of the panel code in particular? When you set .src on an iframe/image/script whatever it's done asynchronously, yes (well, as far as I know).

gogo · 2005-05-19 03:28:49

It seems like either there's some side-effect of how the multithreading works that the onLoad event is cached somehow .. might be a side-effect of how addEventListener works. I'll have to test it without debugging messages, but if anything you would expect the trace messages to slow everything down allowing the race condition to occur.

I'll have to plead ignorance on how threading happens in javascript. It may be that events (and timeouts etc) won't fire until tbere are no instructions to be executed, that is, they wouldn't fire until generate has done. Essentially that the event "threads" are synchronised into a single thread.

gogo · 2005-05-19 03:31:35

http://www.unix.org.ua/orelly/web/jscript/ch10_07.html

So yes, I think the point must be moot and the current code must stop executing before the event can fire.

Yermo · 2005-05-19 03:53:17

gogo wrote:

http://www.unix.org.ua/orelly/web/jscript/ch10_07.html
So yes, I think the point must be moot and the current code must stop executing before the event can fire.

Good find. So for the moment this should work ok in the browsers we're using. I wonder how much code out there assumes this behavior? I would guess quite a bit.

Yermo · 2005-05-19 03:54:34

gogo wrote:

For that matter how does the panel code work. Is that a race condition as well? Does the iframe.src get loaded "in the background"?
What part of the panel code in particular? When you set .src on an iframe/image/script whatever it's done asynchronously, yes (well, as far as I know).

I was looking at it cross-eyed. Disregard.

heyf00L · 2005-08-02 13:33:50

The iframe will not 'load' until it has been attached to the document. If you're using dynamically created iframes you should add the onload listener before attaching it to the document. If the iframe is already in the source, use <iframe src="file.html" onload="foo();"></iframe>

In my work with the midas editor I found it best to put everything in the onload listener.
example: http://derekdev.com/mozilla/iframewithsrc.html

The other big problem with midas is if you change the display or possition styles of the iframe, the editor will act like designMode is off even tho it's on. To fix this turn designMode off and then back on.

Also a focus listener on an iframe window will only work once. I had to settle for a onclick listener and just hope that no one tabs to it.

Xinha Discussion Forum

Announcement

#1 2005-05-17 22:43:29

Potential solution of designMode = 'on' problems in Gecko.

#2 2005-05-17 23:06:28

Re: Potential solution of designMode = 'on' problems in Gecko.

#3 2005-05-17 23:10:28

Re: Potential solution of designMode = 'on' problems in Gecko.

#4 2005-05-18 00:07:59

Re: Potential solution of designMode = 'on' problems in Gecko.

#5 2005-05-18 00:09:42

Re: Potential solution of designMode = 'on' problems in Gecko.

#6 2005-05-18 02:27:25

Re: Potential solution of designMode = 'on' problems in Gecko.

#7 2005-05-18 05:52:25

Re: Potential solution of designMode = 'on' problems in Gecko.

#8 2005-05-18 13:52:54

Re: Potential solution of designMode = 'on' problems in Gecko.

#9 2005-05-19 02:06:27

Re: Potential solution of designMode = 'on' problems in Gecko.

#10 2005-05-19 02:11:48

Re: Potential solution of designMode = 'on' problems in Gecko.

#11 2005-05-19 02:35:25

Re: Potential solution of designMode = 'on' problems in Gecko.

#12 2005-05-19 02:40:47

Re: Potential solution of designMode = 'on' problems in Gecko.

#13 2005-05-19 03:22:47

Re: Potential solution of designMode = 'on' problems in Gecko.

#14 2005-05-19 03:25:37

Re: Potential solution of designMode = 'on' problems in Gecko.

#15 2005-05-19 03:28:49

Re: Potential solution of designMode = 'on' problems in Gecko.

#16 2005-05-19 03:31:35

Re: Potential solution of designMode = 'on' problems in Gecko.

#17 2005-05-19 03:53:17

Re: Potential solution of designMode = 'on' problems in Gecko.

#18 2005-05-19 03:54:34

Re: Potential solution of designMode = 'on' problems in Gecko.

#19 2005-08-02 13:33:50

Re: Potential solution of designMode = 'on' problems in Gecko.

Board footer