ra,

I'm trying to replicate your problem with focus to no avail. I'm not using the bookmarks plugin from beta 6 as I no longer have that beta around. I copied over the bookmark from KM 0.9 (BMPMENU.DLL, 38912k)

I'll keep trying, but wonder if there any other settings I should change to match your setup?

N
W98se

Thanks, ndebord. The bookmarks thing happened only once so far, but I'm constantly getting this "another k-m window pops into the foreground instead of k-m loading the link I left-clicked on"-problem. I'm *not* using the following plugins: Privacy, Layers, External. Additionally to *all* other standard plugins I'm using the session plugin. All I do/try is a simple left click on a link, but instead of loading the linked page/file K-M puts another K-M window into the foreground. Sometimes I have to click on a link three to four times until it finally loads with other windows getting into the foreground inbetween all the time, but usually this happens only once per link.

What do you mean by BMPmenu.dll? That's because of the crashing problem at the end, is it?

BTW: K-M just crashed the fourth time *today* (this time in K-Meleon.exe and I can't remember doing s.th. unusual, there were just a few windows loading in the background). I didn't have so many crashes with beta7+ at all...

Another problem I encountered yesterday: Gecko somehow locked up. Pages were loading endlessly without any progress at all. The K-Meleon part of the browser (e.g. Preferences) still worked though. But can't seem to repro it (too ;-/).

Yes. BMPmenu.dll crashes at the end, that is after closing the browser...
Are memory allocation pointer bugs causing the crash when the dll closes?

I've also had several lockups and strange display updates depending on number of webpages loaded. It is imposible to repeat the crash when I go back to these sites. This could be because memory allocation by the browser is never done exactly the same way twice as you have different order of downloading memory components ( html, jpg, gif, css etc ).

Are we seeing the browser become unstable, more likely to crash, as it being used over a long time? More problems as memory allocation becomes more and more corrupt?

Slashdot and digg.com had an article on Firefox memory bugs awhile back, is Gecko 1.8.0.2 the problem?

While it may work better on XP, Win 98 is the "canary in the mine" for minor design bugs. If you get it working on 98 it most like works on XP. And Microsoft's hidden helping hand on XP memory allocation could be hiding memory bugs.

Is the BMPmenu.dll used for the advanced preferences? I've noticed some checkboxes, ones that should work, will not display the check mark. But I don't remember which ones now.

I think Dorian is close with this release. He can't be faulted for the Gecko problems he mentioned. Do we need to wait for Gecko 1.8.0.3? Silly little last minute memory bugs drive me crazy in my programs too!

-- Jack

Glad I decided to stick with 1.0b7 rather than trying 1.0RC0 because 1.0b7 has been very reliable indeed - just one or two niggles (under Win 2000+SP4 and Win XP). Seems like the Gecko latest update has not been a happy one, and caused Dorian needless trouble.

Is the BMPmenu.dll used for the advanced preferences?

No, they are XUL.

I should of said: Used in the gui display of advanced preferences.

If XUL is used to do that, then..

I would guess that BMPmenu.dll is buggy or the XUL used to define the advanced preferences, causing the display problems. That one buggy dll might be cause for a lot of seemingly different problems. Like not being able to save or edit bookmarks because the BMPmenu.dll is faulty. As well as the layers opening bug and crashing when unloading the BMPmenu.dll at brower close!

-- Jack

Jack,

I wonder if ANY of the even earlier bmpmenu.dll's was better than the current crop?

N

Found some time tonight to play around and think about the problems..

Now tonight the Advanced Preferences worked perfect! Slow, but perfect

But bookmarks has never worked right. I can not store a bookmark.( alt-B Add ). After doing (alt-B Edit ) bookmarks and clicking on Import Favorites, KM made a folder and imported my IE urls. Then I clicked on "Ok" to close the Bookmark window and BMPMENU dll crashed. Re started KM tried it a second time and it created another folder, with the same name and imported my IE urls a second time. But this time it did not crash on clicking "Ok". And the urls in the imported directory(s) work fine and can be edited too.

But I still can not add a new url to bookmarks.

So maybe BMPMENU DLL is working and it's the bookmarks dll or it's XUL that has the problem. Bookmarks dll could be calling BMPMENU dll with invalid parameters and that causes the crash or worse a memory corruption. You normally call a dll at least twice in every program. The first time at program load to initialize it, i.e. load the bookmarks html file. Then, even if you don't need to use the functions in the dll, i.e. use the bookmarks, you call it a second time to close it when you exit the program, i.e. to make sure to save or re-save the bookmark html, and to release memory used by the bookmarks html. That is two reasons why it could crash at browser exit time.

Dorian said bookmarks wasn't working right and he made changes. Something about two bookmark html files... Maybe two different pointers exist to point to the bookmark html in memory. One is allocated memory, and the other is pointing to an undefined location. Could be the ADD bookmark function is using a different pointer.than the EDIT function. Which is also being used to free memory at close, something XP handles for the programmer better than Win 98 ( To keep XP from crashing with older legacy programs, they could be doing an "okay you want to close the program so we will clean it up for you." ). So on Win 98 it crashes, and on XP the memory is properly deallocated...

So while it appears to work on XP. A "wild" bookmark pointer in XP would have a different effect than in Win 98. So maybe it effects the layers memory on XP? And because of larger memorys on XP systems many times the wild pointer doesn't do anything wrong.

Otherwise this build runs beautiful.

-- Jack

Please don't go throwing wild guesses like that.


@kko:

The Configuration (Edit -> Configuration) menu is empty when the macros plugin is disabled.


rmn

@rmn: Should be fixed in the next release. Thank you for reporting!

Jack & rmn,

Just a small aside. Trying to help in debugging a beta browser is not an easy task. Being wrong sometimes is part of that process and I would rather have wrong than no posts at all. I've been wrong more times than I care to remember on what I "thought" was going on with KM, but then as all here know, I am not a techie, just a fan.

Meanwhile, the idea that K-Meleon has reached RC status is grounds for a small celebration. If you look back, not all that far into the past, we were at a stage where it looked like the whole ballgame was shut down for good. And then we collectively came forward with an incredible burst of energy and look where we are today. Lots of improvements, several good versions, lots of diversity and more input into the process. I like the world of KM a lot better now than say, a year ago!

<VBG>

N

Fair enough. Anyway, is anyone maintaining the installer? There's a few bugs regarding the components selection which should really be fixed before the release.

@rmn - AFAIK. No dedicated maintainer. But:
alain is working with installer and has knowledge about it.
Dorian also has a well advanced script.
Fred must also have some knowledge.

@ndebord - You are right - let's clebrate - I bought us 20 bottles of "Einbecker Mai Bock" will You come by to help me with them? - else i celebrate on my own ; )

@guenter:
Have a beer for me - would join you if I could!

Hope the latest Gecko update hasn't caused Dorian too many lingering problems, because things are (were?) obviously so close to a final release. I've used the 1.0b7 intensively for some time as my daily browser and it has performed very well indeed.

Hope the latest Gecko update hasn't caused Dorian too many lingering problems, because things are (were?) obviously so close to a final release.

It has. And there are still problems around as it seems. ;-(

Guenter,

Because it's you, I'd actually drink a beer, but being of French heritage, I'd much prefer a good bottle of Red Wine. Now that you Germans are producing good red wine once again, I think we could work on a very satisfactory hangover with some very good booze!

<sly grin>

N

Douglas,

From what I've heard here, the new versions of KM based on the 1.8.2 Gecko code are necessary because of security issues. I too found the 1.0beta7 version very decent and even more so, am interested in the NON-XUL versions. It seems that we have several betas now that are first rate.

My everyday browser, until all this gets sorted out, is still Brian's patches on KM 0.9, but that is just me. I routinely try out my preferences and macros in the newer versions with varying degrees of success.

N

I find that KMSM 1.0RC0 is pretty good. Not good enough yet to replace KMS 1.0beta7, but considering use of new Gecko code, not bad at all.

N

How to enable the flashblock?

Edit/Advanced Preferences/Page Display/Content Filters

Yogi

@ndebord (& Douglas)
Dorian and hao have been using old code from the 1.8.0.x branch (from late january and early february). They have been using 1.8.0.1 geckos from before the cairo graphics layer started to be turned on.
Dorian's attempt to move to 1.8.0.2 seems to be his effort to balance "struggling with bugs" against "running off of dead-end code".
AFAIK the last 1.8.0.1 geckos and the 1.8.0.2 geckos had a lot of the cairo backend running, but they had security problems initially, and the security fixes caused bugs and incompatibilities. I believe it was the 1.8.0.2 problems that prompted the early release of the 1.8.0.3 and then 1.8.0.4 geckos (some of the 1.8.0.2 based Firefox1.5.0.2 nightlies have since been removed from the mozilla ftp server).
I think that Dorian's move to 1.8.0.2 was important both because it got K-Meleon 1.0 away from some of the old graphics code, and also because it is more nearly like the code needed by the current 1.8.0.4 geckos.

Stuart Parmenter (& maybe Vladimir Vukicevic) have a plan explaining the graphics move at:
(h t t p : / /) wiki.mozilla.org/Mozilla2:GraphicsPlan#The_Plan.28tm.29
and it looks like they are nearly done shuffling the graphics interface on Windows & Linux, but are still working on Mac... but they still haven't checked off their
"Break the world"(turn on thebes/cairo as default rendering back end) entry,
or their "Remove old graphics code!" entry...
so there still may be some drama coming.

This is an awfully long post (and I don't know how much of it the forum will let through),
but I think that this reflects the current situation:

(Gre1.9.0)............................................(Firefox3.0)
Gre1.9a1....Seamonkey-1.5a.............................Firefox-3.0a1-Minefield
Gre1.9a1...........................(cairo beta builds).ausgamer Sports Chook
Gre1.9a1...........................(cairo beta builds).Firefox1.6a1Cairo
------1.8.1/1.9----------platform-compatibilty-barrier---------
(Gre1.8.1).(going to drop Win9x support for Firefox2).(Firefox2.0)
Gre1.8.1a2..Seamonkey-1.1a.............................Firefox-2.0a2-BonEcho
------1.8.0/1.8.1--------product-compatibilty-barrier----------
Gre1.8.0.4..Seamonkey-1.0.2............................Firefox1.5.0.4
Gre1.8.0.2..Seamonkey-1.0.1..K-MeleonCCF 0.05.5_Tabs...Firefox1.5.0.2-20060419
Gre1.8.0.2..Seamonkey-1.0.1..K-Meleon 1.0RC0...........Firefox1.5.0.2-20060419
-------------------------evolving-Graphics rendering-break-------------
Gre1.8.0.1..Seamonkey-1.0....K-MeleonCCFNoXUL_Tabs.....Firefox1.5.0.1rc
Gre1.8.0.1..Seamonkey-1.0....KMeleonNXtest_Tabs........Firefox1.5.0.1rc
Gre1.8(2005)Seamonkey-1.0b(Nov.2005)...................Firefox-tabs.2005**
------1.7/1.8.0----------platform.compatibilty.barrier-(and confusion)
Gre1.7.13...Mozilla-1.7.13...K-Ninja Samurai v1.0.2....Firefox1.0.8
Gre1.7.13...Mozilla-1.7.13...Km-0.9.13_Layers..........Firefox1.0.8
Gre1.7.13...Mozilla-1.7.13...K-M_Beanboy0.9.13_Layers..Firefox1.0.8
Gre1.7.12...Mozilla-1.7.12...Km-ME1.7.12-mod-fromCD....Firefox1.0.7
Gre1.7.12?..Netscape 8.1 is based on Firefox 1.0.7.....Firefox1.0.7
------------------in need of update or better documentation----
Gre1.7.??...Mozilla-1.7.??...(OpenCD) CDbrowserKit(a GUI, not a web-browser)
------------------desperately in need of update (obsolete)-----
Gre1.7.8....DocZillaBrowser2.7.0pre1-20050708(free for non-commercial use)
Gre1.7.5-20041220............Andkon's K-Meleon_Layers
Gre1.8a2.....................Km-0.8.2+Wechselbalg_Layers
Gre1.7.2....Netscape 7.2 is based on Mozilla 1.7.2
Gre1.5......Beonex Communicator 0.8.2(free for all personal uses)
Gre1.0.2....Netscape 7.01 is based on Mozilla 1.0.2
Gre1.0.1....Netscape 7.0 is based on Mozilla 1.0.1
- - - - - -
note1: This list does not include Douglas's portables, Brian's updates, and the many
translation efforts (most of that work can be applied, with effort, to many of these
structrally different builds).
note2: Gre1.8 K-Meleons can be upgraded (theoretically, with much effort and many bugs)
to Gre1.9a1
note3: most of the tab-builds, and K-Meleon 1.0RC0_Layers and Km-ME1.7.12-mod-fromCD use
new locations for the Profiles
note4: most of the tab-builds can be converted back to layers by replacing the
K-Meleon.exe and the kplugins folder with those from a layers-build (but that may break
some layer-related macros in macros.cfg and the references to them in menus.cfg and
toolbars.cfg, which then must be modified)
note5: Km-0.8.2Wechselbalg_Layers can NOT be completely updated (because it is a static
build, that has some code that is normally stored in .dll files integrated into the
K-Meleon.exe), it may be possible to partially update it (or to compile a new static
build).
note6: Some "ausgamer Sports Chook" builds and all "experimental Cairo" builds are
attempts to force use of some parts of cairo svg graphics that exist in recent Seamonkey
and Firefox builds. Some "ausgamer Sports Chook" builds are made from the Gre1.9a1"Trunk"
and can be considered current, but the "experimental Cairo" builds are probably all
"Dead-End" products for Windows-OS, since they have not been released for Windows since
late Feb 2006. Newer Windows builds have since been released in Gre 1.8.0, 1.8 and 1.9a1
which implies that cairo svg graphics are in use in recent Windows builds.
note7: **firefox-tabs.2005 is not structurally different from Firefox, it was just an
experiment in making the display of tabs easier to use.

Sorry I didn't include Hao' K-MeleonCCF ME 0.06, but I haven't used it yet and I don't know what gecko it's built on.

vpowell,

Of all that list, this one struck my eye:


Gre1.8.0.4..Seamonkey-1.0.2............................Firefox1.5.0.4

From my understanding, that is a stable branch, both for FF and for Seamonkey.

N

1.8.0.4 4 xulrunner = good too and i experimentally run it with one of Dorians exes.
1.8.0.4 monkees will probaly run well with Dorians exes : )

1.8.0.2 - we have trouble with experimental chromes from that.
possibly the version is not good with k-m.
We had that with some 1.7.x on 0.9 too, right?

It would be nice if Dorians exes were as independent ( or more ) of a specific GRE as
Ulf 0.9 exe is. Sort of all-fuel-burner for 1.8 and 1.9.x GREs.
But i think it is much like that already.

Greetings

@ndebord
Yes, that is the important line, but it isn't as simple as it looks
The latest Firefox 1.8.0 (firefox/nightly/latest-mozilla1.8.0) is Firefox 1.8.0.4 (firefox-1.5.0.4.en-US.win32.zip)
and the latest Seamonkey 1.8.0 (seamonkey/nightly/contrib/latest-mozilla1.8.0) is Seamonkey-1.0.2
But Seamonkey-1.0.2 is only available in os2 (seamonkey-1.0.2.en-US.os2.zip).
The latest Seamonkey 1.8.0 for Windows (seamonkey/nightly/contrib/2006-04-18-06-mozilla1.8.0) is Seamonkey-1.0.1 (seamonkey-1.0.1.en-US.win32.zip), and that is running on Gecko 1.8.0.2 (20060418)
I don't know how that relates to the available source code, but the parts of the recent builds that are made from binaries are limited to Gecko 1.8.0.2 (20060418) so Dorian and Hao are roughly working on the limit of the stable branch.
-------------------------

@Dorian (& Hao)
Where do you get your parts?

K-Meleon 1.0-SM (rc0) "about:" page says
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060419 K-Meleon/1.0

SeaMonkey 1.0.1 (2006-04-18-06) "about:" page says
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060418 SeaMonkey/1.0.1
-------------------------

@guenter
What are you chopping up to get 1.8.0.4 xulrunner parts?

hi from new-york,
-vincent

The date is simply the build date, it doesn't say anything. You could e.g. compile old source code today and it would look recent...

@vincent
Do You mean what application i slaughtered?

i played around a little. First i took a used "Songbird".
Songbird was surprised when harnessed to run under a k-m

() - ROFL:

But now i took a 1.8.0.4 xulrunner directly from Moziila.org.

i run our exe with any engine that i can persuade to work.
A dynamic FF? a Xulrunner? - i do not care.
What i look after? = how the engines improve. Which has best look and feel.
Apart from being my favourite browser - k-m is the best jockey to test-ride GRE.

SeaMonkey: names - i assume they have not changes the name to 1.8.0.4 yet.
They probably still share similar code base with FF based on 1.8.0.4 GRE.

Thx for the interesting links.
The windows version 1.8.0.2 might be here // OS/2 is behind?

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.0.2/

@Vincent: Thanks for the detailed info.

@guenter
Yes, you are right.
In seamonkey/nightly/latest-mozilla1.8.0 there is a Seamonkey-1.0.2 (seamonkey-1.0.2.en-US.win32.zip of 16-May-2006 11:12) and
in seamonkey/nightly/candidates-1.0.2 there is a Seamonkey-1.0.2 (seamonkey-1.0.2.en-US.win32.zip of 16-May-2006 16:19).
On the SeaMonkey 1.0.2 "about:" page the userAgent says:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2

SeaMonkey 1.0.2 (like Firefox 1.5.0.4) runs on gecko 1.8.0.4
[The reference to a Firefox 1.8.0.4 (in the post of 05-18-06 14:20) was a mistake, a "typo" caused by having to type so many complicated numbers]

and actually I was wrong about the latest win32 SeaMonkey
there have been SeaMonkey 1.0.2's available for windows since May 8th (seamonkey-1.0.2.en-US.win32.zip 08-May-2006 11:49)

So I guess Dorian can try gecko 1.8.0.4

@ra
Yes, it's only the date of compiling, but it one of the few ways I can differentiate between the versions.
The best thing would be to have everyone say from what url they downloaded the nightlies.

@Dorian (& Hao)
I think I figured it out. You were using something like the SeaMonkey 1.0.1 at
nightly/contrib/2006-04-19-03-mozilla1.8.0