Greetings,

I am new to K-Meleon. The past several days I have been seriously learning my way around the browser and overall I am quite pleased.

I'm using K-Meleon 1.02 and NT4 Workstation (SP 6a). I verified all DLLs as described in the Known Problems FAQ. My box is rock-solid stable and I rarely witness BSODs or other types of crashes.

I am sharing what I believe are some K-M bugs.

1. Sometimes the session restore feature restores previously closed pages. I cannot replicate this or force duplication, but occasionally when I open K-M and I am certain that I had no open pages when I closed K-M, K-M nonetheless opens previously opened pages.

2. The session restore feature does not remember which page had the focus when I closed K-M. All previously opened pages open, and the original tab placement is correct, but the focus is always on the first tab.

3. As reported in another bug thread, I cannot use the bmp or rebar plugins on my NT4 box. I am not into skins so I am not affected, but trying to use those features are nonetheless bugs that causes K-M to crash without fail on my box. I can only wonder how many people using older hardware, much like me, who try to investigate K-M because of the claim of being the "little browser that could," discover that they cannot load K-M or that they cannot see the menus. I have no issue with people with faster hardware and Active Desktop installed using these plugins, but I think the installer, or perhaps the default installation, should be to have these two plugins disabled, packaged with ample warning documentation. My own observation, especially because I also use GNU/Linux, is that a lot of people steadfastly are not buying new hardware. Many people who remain with Windows or dual boot with GNU/Linux, continue to use their NT4, ME, 95 and 98 Windows. That Microsoft has pompously declared these OSs "obsolete" is irrelevant to many users who continue using these OSs. I am beginning to warm up to K-M (I have been using K-M as my preferred browser the past few days), but I think disabling these plugins as the default configuration is the correct approach that would win over new users.

4. I was disappointed to see that K-M uses XUL. Part of my desire in migrating away from Firefox toward K-M is that XUL is painfully slow on older hardware. Yes, after new users get their K-M configured as desired, the Advanced Preferences dialog box is used only occasionally, but I would like to see this XUL stuff disappear totally. However, this dialog box performs a no-no. Using the Advanced Preferences creates a XUL.mfl file in either the K-M program Profile\default directory, or in C:\WinNT\Profile\default. I have been unable to duplicate the latter location and I am willing to shrug with that one, but creating a XUL.mfl file in the program directory is a no-no. I always have disliked this file, and that the file even exists is evidence that XUL is slow and that developers created this cache file simply to overcome that slowness. Regardless of my philosophy, the proper place to create this file is in the user's profile directory, or better yet, in a location specified in the pref.js file. Possibly somebody will respond that the user's profile directory is not the correct place if one wants to support roaming profiles, and if the K-M developers agree, then the correct solution is to specify the location of that file through the prefs.js or all.js files. But please, do not allow this file to be created in the K-M program directory.

5. Occasionally when I start K-M the program opens the Advanced Preferences box. I can replicate this problem without fail: 1) Open K-M. 2) Do not open any other pages. 3) Open the Advanced Preferences. 4) Close the dialog box using the Advanced Preferences Close button. 5) Exit K-M. 6) Open K-M---and the Advanced Preferences box appears.

Repeat steps 1 through 4, but before exiting K-M, click on the Layer/Window toolbar Close button (even while no pages are open), and then when opening K-M the Advanced Preferences will not open automatically.

6. Not exactly a bug and more of an oversight, but the macros.cfg file contains hard-code that assumes a program directory location of C:\Program Files. Although this is the correct location on many computers, this is not the case on my box or possibly a networked boxed. The correct location for the Program Files directory, and the Program Files\Common Files directory is stored in the registry and this where the macro should retrieve this information. The keys are stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion using the ProgramFilesDir and CommonFilesDir string keys.

Please know that I am trying to help. I have been using K-M the past several days, I am reasonably content with performance, and I suspect K-M is going to become my preferred browser.

Thank you.

Peabody>> I think disabling these plugins [bmp and rebar] as the default configuration is the correct approach that would win over new users.

Yes, couldn't agree more. There has been some discussion in the past about what should and what should not be enabled in the default. Your idea here should be the norm, not the other way around.

Didn't see the session restore bug yet, but will look for it now.

As for XUL. KM uses some XUL, but not a lot. Aggreg8 is the main one and the adware stuff which is fairly new does too, but I don't use that part of the browser.

The rest uses macros and I have lots of external apps loaded up inside KM on hot keys.

I have never seen the program open up in advanced preferences

As for the location of KM in macros.cfg saying C:\program files\k-meleon. I find no such line in my macros.cfg, but then I did not allow KM to be setup using the registry (I unchecked the multiple box and went for the alternative, which is PROFILE.INI in the main program folder. A decision based upon how KM used to be setup as a "well-behaved app" with everything in the program folder(s), not windows applications or registry.

w98se

N



Edited 1 time(s). Last edit at 11/21/2006 02:34AM by ndebord.

Quote

As for the location of KM in macros.cfg saying C:\program files\k-meleon. I find no such line in my macros.cfg...

The "Get IE" macro is hard-coded to C:\Program Files\Internet Explorer\iexplore.exe. The macro should instead retrieve the location of the Program Files location from the registry key noted above.

The macro is functional as is, but on my computer the macro would fail because I long ago modified my registry to point the entire Program Files directory to my D: partition. Network admins have done similarly for their networks. All I am offering here is that the K-M developers should update/revise that particular macro so that the Program Files location is not hard-coded in the macro code.

I cannot test the macro because I also long ago stripped IE from my box. For my own purposes I might copy the GetIE macro and create a similar macro to open web pages in Firefox and Opera. As I mentioned, this is not a bug, I'm just offering an improvement hack and hoping the developers mod that tiny section of macro code.

1-2) kko works on improvement of session restore.
He also altered IE macro ( Enaitz made the guiny pig - ahem beta tester ;-)
3) possibly a windows dll update problem, MS & its many dll with the same name :-(.
4) there are experimetal versions without XUL. Problem: we need XUL = ready things.
5) fairly new panel, new version already in test.
6) k-m has few skilled supporters. some codes range back to times when we still had devs that had program files (folder). Only with the newest modular macros generation more ppl and less skilled ppl can work parallel & transfer exaples to new uses.
greetings to US from DE

1. The session plugin's session recovery is taking the action when km wasn't closed properly - even if you haven't noticed. You can disable the plugin.
2. The session plugin's capabilities are currently very limited. Km 1.1 has improved macros in this regard (but they won't remember the focus either).
3. I totally agree.
4. You're right, the XUL.mfl is created in the wrong place (should be the profile directory).
5. That is a macro issue when you start km with the last session. Should already be resolved in 1.1.
6. IE's command line is already read from the registry. So, this macro is not likely to fail (my Program Files are on D:\ too). That semi-hard-coded path is only a fallback (especially for Win9X systems where it is normally correct). Nevertheless, thank you very much for pointing me to the ProgramFilesDir key. I've searched this key for a long time and never found it (maybe the location was too obvious?).

Can anybody confirm the existance of the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir
for Win9X? (Otherwise I can't use it.)

kko,

Don't know if I can help you here, but this is what I found in RegEdit.

KKO>> Can anybody confirm the existance of the key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir

NOT exactly. I can follow your key info up to this:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\

At that point I do NOT see

\ProgramFilesDir


W98se

N



Edited 1 time(s). Last edit at 11/21/2006 03:00PM by ndebord.

@ndebord: Actually, ProgramFilesDir is a date (not a "directory") and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ is the location ("directory") where you should find it. But it wouldn't surprise me when it's not there on your 9X machine...

@kko,

No this key doesn't exist, but there is a key which perhaps can be used:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE
@="C:\PROGRA~1\INTERN~1\iexplore.exe"

it's just necessaery to test win version.

Two others little bugs in 1.1a2:

1) in kmeleon.js, macros(up_directory) instead macros(Go_Up)

2) km search is broken (with new forum)

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

Edited 1 time(s). Last edit at 11/21/2006 07:34PM by JujuLand.

No this key doesn't exist
Thank you for the confirmation!

but there is a key which perhaps can be used:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE
@="C:\PROGRA~1\INTERN~1\iexplore.exe"
That's the key I do already use!

it's just necessaery to test win version.
This key works in all versions.

Two others little bugs in 1.1a2:

1) in kmeleon.js, macros(up_directory) instead macros(Go_Up)
Yes, I've alreday noticed it.

2) km search is broken (with new forum)
Yes, somebody else already reported it. 1) and 2) will be fixed in the next release.

Thanks, Alain.

Quote

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE
@="C:\PROGRA~1\INTERN~1\iexplore.exe"
That's the key I do already use!

But this won't work on my box or any box that a network IT person has configured to look on the network. That is really the primary point of my original post. That is, you cannot assume all programs are located in the infamous C:\Program Files directory. On my box all programs are located in my D: partition. On a network they could be stored at any drive letter.

The registry key I noted above was introduced in NT4, which I use and has continued through W2K and XP. I am not surprised the key is not found in the DOS-based Windows.

Additionally, after posting yesterday, I decided to investigate further to possibly help with this idea. I noticed that Opera no longer uses the above App Paths registry key. Therefore, for this macro to support opening a web page in Opera, the App Paths registry location will not work either!

With that said, why not instead use the same approach used with the external text editor to view source code? That is, instead of embedding all of this wonderful stuff into a macro, and instead of trying to outguess users and the large number of possibilities, merely use the prefs.js to store the location of these external programs. Much easier I think. Like the external text editor, eventually end-users will need a Preferences interface to add the program location, but for the interim your beta testers will not mind manually tweaking prefs.js to add those program locations. That much at least provides the beta testers something to test.

Quote

1. The session plugin's session recovery is taking the action when km wasn't closed properly - even if you haven't noticed. You can disable the plugin.

Well, the good news is that I have been unable to replicate this problem the past 36 hours or so. So perhaps the problem was my newbieness!

Quote

2. The session plugin's capabilities are currently very limited. Km 1.1 has improved macros in this regard (but they won't remember the focus either).

Just an idea, but the old Session Saver extension in Firefox (not the new embedded feature of 2.0, but the original extensions), saved all of its session data in prefs.js, including which page should have the focus. So perhaps you could do something similar? BTW, where is the current session data stored?

Quote

4. You're right, the XUL.mfl is created in the wrong place (should be the profile directory).

Ah, that implies getting fixed?

Quote

5. That is a macro issue when you start km with the last session. Should already be resolved in 1.1.

Okay!

Quote

Nevertheless, thank you very much for pointing me to the ProgramFilesDir key.

Glad to help!

Quote
Peabody
where is the current session data stored?

In prefs.js.

Quote
Peabody

Quote

4. You're right, the XUL.mfl is created in the wrong place (should be the profile directory).

Ah, that implies getting fixed?

Ah, that implies me passing the information on to the responsible person.

Quote
Peabody

Quote

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE
@="C:\PROGRA~1\INTERN~1\iexplore.exe"
That's the key I do already use!

But this won't work on my box or any box that a network IT person has configured to look on the network. That is really the primary point of my original post. That is, you cannot assume all programs are located in the infamous C:\Program Files directory. On my box all programs are located in my D: partition. On a network they could be stored at any drive letter.

On my box the Program Files directory is called Programme and is located on drive D:\, drive C:\ does not even exist. Nevertheless, the macro works.

The HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\ data base provides the only way to determine installed applications' command lines in a standardized manner on all versions of Windows down to 95. This data base is used by the OS itself (Context menu 'Open With' > 'Select Application...' and the file type manager) aswell as by third party applications.

The key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\<AppName> is usually added by the application's installer and specifies the app's fully qualified command line - wherever you installed it i.e. whatever the host drive letter or the (localized) name of your Program Files directory is.

1) When an application's installer is not adding any information to the App Paths data base or is adding invalid information, it's not my fault. Blame the installer. (In this case you might use application specific registry keys to generate a valid command line.)

2) When you've rendered the information stored in your App Paths data base invalid by manually tweaking your OS, it's not my fault. Blame yourself. (In this case you should correct your data base because the information stored there is not only used by my macro, other applications use it aswell.)

Quote
Peabody
The registry key I noted above was introduced in NT4, which I use and has continued through W2K and XP. I am not surprised the key is not found in the DOS-based Windows.

And that's why it's unfortunately useless. K-Meleon works an all versions of Windows down to 95. So the macros also have to work on Win9X. In addition to that:
- On NT4 and above you don't need to read the registry to get the location of the ProgramFilesDir. It's easier to use the %ProgramFiles% environment variable.
- When an application is NOT installed in the ProgramFilesDir, it's useless to know that directory's location. The way via the App Paths data base will work nevertheless - when it doesn't be refered to 1) and 2).

Quote

When an application's installer is not adding any information to the App Paths data base or is adding invalid information, it's not my fault.

I agree. I was only informing the devs (you?) that for whatever reason, Opera no longer installs a registry key in App Paths. I was placing no blame, only providing information.

Quote

When you've rendered the information stored in your App Paths data base invalid by manually tweaking your OS, it's not my fault. Blame yourself.

I'm unsure where this came from. I have not modified the registry in any invalid manner. Perhaps something got confused in the thread.

Quote

On NT4 and above you don't need to read the registry to get the location of the ProgramFilesDir. It's easier to use the %ProgramFiles% environment variable

Just some additional information: this environment variable does not natively exist in NT4. I've been using NT4 for 9 years or so and I never have recalled seeing this env. variable. I just now checked and there is no such variable. I do know that with W2K, additional env. variables appeared that were never included in NT4. The %AppData% variable comes to mind because after I discovered that W2K included this env. variable, I created the same in my NT4 box because the variable solved some configuration preferences I had. But the variable is not native to NT4 and neither is %ProgramFiles%. Just so you know.

Quote

When an application is NOT installed in the ProgramFilesDir, it's useless to know that directory's location.

I agree. Between the App Path keys and the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir key you really have no hope of finding a file programmatically. My only point to my original post was that one should not assume that the Program Files directory is located in the C: drive. Not that you couldn't use that location to check, but there is no guarantee that the directory is located on C:.

I agree your approach is just fine with trying to cover the bases. I'm not trying to throw sand into the gears, just trying to help. The real problem is that the Microsoft people have seldom remained consistent with their design criteria---creating too many possibilities. This started decades ago with the TMP and TEMP environment variables. All of these IF-ELSEIF-ELSEIF-ELSE-THEN possibilities creates bloat. Miss or ignore one of these numerous possibilities and a program fails to function properly and end-users get frustrated. Many people have complained about all of these inconsistencies for the past two decades.

Quote

Quote

On NT4 and above you don't need to read the registry to get the location of the ProgramFilesDir. It's easier to use the %ProgramFiles% environment variable

Just some additional information: this environment variable does not natively exist in NT4. I've been using NT4 for 9 years or so and I never have recalled seeing this env. variable. I just now checked and there is no such variable. I do know that with W2K, additional env. variables appeared that were never included in NT4. The %AppData% variable comes to mind because after I discovered that W2K included this env. variable, I created the same in my NT4 box because the variable solved some configuration preferences I had. But the variable is not native to NT4 and neither is %ProgramFiles%. Just so you know.

Thank you for the clarification! I guess, I got it right now

Quote

My only point to my original post was that one should not assume that the Program Files directory is located in the C: drive. Not that you couldn't use that location to check, but there is no guarantee that the directory is located on C:.

I know that (as I already said, I do not even have a C:\ drive on my system). It's only a fallback for when the registry lookup fails. In this case there's no other chance. And it's not very probable that both the registry lookup fails and the ProgramFilesDir is not located on C:\...

Quote

The real problem is that the Microsoft people have seldom remained consistent with their design criteria---creating too many possibilities.

Not only Microsoft is to blame. Also the application developers have to take their part: Opera should add itself to the App Paths data base. It's as simple as that!

Quote

Opera should add itself to the App Paths data base. It's as simple as that!

Agreed! I was surprised when I discovered otherwise.