Any application that uses embedded Gecko (K-meleon included) completely freezes every time Gecko renders a page (canÂ’t open host appÂ’s menus, any menus that are open become unresponsive, canÂ’t interact with any portion of host app). This is especially noticeable on slower machines (Pentium 200, 128MB RAM, Windows 98, broadband connection).

IÂ’m sure there is a Mozilla bug for this as the behavior has been around for a very long time and may have existed since Mozilla was created. But I canÂ’t seem to find the bug number.

Affected applications include K-meleon (embeded), Winamp 3 mini-browser
(ActiveX Control), TopStyle (ActiveX Control), Scope (ActiveX Control). I am
using a recent nightly build. I havenÂ’t downloaded a recent version of
MFCEmbed, but I remember it being afflicted with this problem a few months
ago.

Since Kmelon is suitable for lower-end computers, IÂ’m surprised this problem hasnÂ’t surfaced more often. Am I delusional or has other people suffered similarly?

Is this freeze you mention momentary or completely over the space of time? I haven't noticed anything like you mention, so some more info would help.

It is momentary -- while the Gecko engine renders, and if it is a large document with complex tables, the freeze will last for several seconds. Even if itÂ’s some simple document that takes 0.1 seconds to render it will still freeze the host app for 0.1 seconds. When rendering is done, the host app is responsive once again.

Try opening a Slashdot page with nested comments at -1 threshold. The following will do:

]http://slashdot.org/comments.pl?sid=33721&cid=0&pid=0&startat=&threshold=-1&mode=nested&commentsort=0&op=Change

Now, open the File menu and move your mouse left and right opening all the menus until the page finishes loading. When Gecko starts to render, the menus will stop responding to your mouse movements. Kmeleon does not become repsonsive until Gecko finishes rendering and the page displays. Reproducible with broadband and modem connections

Please donÂ’t say this is supposed to happens on all documents. Internet Explorer does not freeze for the whole duration of rendering, neither does Mozilla for that matter.

If youÂ’re using a fast machine (greater than 400MHz and especially above 1GHz), donÂ’t bother looking for it. The problem may be some architectural problem having to do with timers where latency is especially noticeable on slow machines.

Fast machine means these delays are too small to notice.
Architectural problem means it hard to fix and will not get resolved until people like me stop assuming it will get fixed and start to give it some attention.

Bug 91643 - “All Mozilla windows frozen during some stages of loading a page”, is similar but relates only to Mozilla and not embedded apps. This bug describes short spasms where Mozilla freezes, not the long duration of application freeze described above:

http://bugzilla.mozilla.org/show_bug.cgi?id=91643http://bugzilla.mozilla.org/show_bug.cgi?id=91643]http://bugzilla.mozilla.org/show_bug.cgi?id=91643]http://bugzilla.mozilla.org/show_bug.cgi?id=91643http://bugzilla.mozilla.org/show_bug.cgi?id=91643[/url][/url]
(see comment #16 for full explanation)

Hopefully this is more than enough information.

Oh well, my machine is faster than 1Ghz, so that explains why I haven't noticed anything :-)

My crappy message formating... grrr.

I have P200, 80MB RAM, Win98, 56K modem. My K-Meleon's menu doesn't stop responding completely (stop for 1-2 seconds, normal for 8-15 (sometimes more than 20) seconds, stop again, normal again). I don't think that's unusual for my slow machine and my (very) slow Internet connection.

I suspect the reason I freeze completely is because with broadband connections Gecko has large chunks of data to render in a short amount of time, thus it leaves no processor time left for the host appÂ’s thread.

Modem connections, I suspect, provide Gecko with smaller chunks of data over larger spans of time and does not hog the CPU.

Netzero is the only access I have to a modem connection. On a Pentium 200, Netzero is a CPU hog itself.

This issue is important to me because all open K-meleon windows freeze. I cannot switch to another windows while the first one renders (which may take many seconds).

Luc, I'm not sure this can be fixed without some major architectural changes to make KM more multithreaded.

i can confirm the momentary freezing as well, for me the menu bar in the application using gecko goes totally blank (white) as well as the scroll buttons while rendering the page, its pretty darn weird, but then im on a slow computer 400mhz, 128ram, 56k dial-up

Aye, mateys, with my lowly PentiumII there are little freezes. Can't scroll while loading in background, and menus start to freeze on the third or so. (I like to open several at once) Switching windows gets very sticky on a heavy load. Nice to know it isn't just me. :-)

Just so everyone knows, the Bugzilla # is
150801.