K-Meleon apparently does not handle links to HTML files on the local machine that do not have the appropriate extension. This causes problems with downloaded webpages (eg. by a web crawler that grabbed a site that uses PHP) and hampers offline browsing. Seems to have no difficulty loading such pages when dragged from Explorer or typed in the url: field however. I'd try fix it myself but I 1. don't know any win32 or MFC and 2. don't have a suitable compiler and thus I'd be unable to test any changes I'd make.

so the problem only happens with file->open ?

Oops, should have been a little more clear. If there's a page on the local machine, and it links to another page on the local machine, that link will appear to be broken (eg. clicking on it doesn't do a damn thing, just like in Mozilla) if the page it links to does not have an appropriate extension. A prime example is trying to view a web site downloaded with a web crawler, which uses some form of server-side page generation (eg. PHP, pl scripts, ASP, JSP, server-side javascript, etc. etc.) that as a result causes these files to be given an extension other than htm, html, css, etc. etc. etc. So far, I've only tried it with plain html files, and it turns out that file->open works just fine, provided (of course) that you change the filter from htm/html only to all files. Drag and drop worked fine as well. Apparently, k-meleon doesn't open these local files as htm/html if they are not named as such for whatever reason. Strangely, opening these files on a remote server works just fine, as the same sites that don't work offline with this browser (and do work with IE, Netscape, and all versions of Mozilla that I've tried, which means most revisions from 7 and up) work just fine when used normally over the internet.

Hope that clarifies my problem.

link clicking is handled by mozilla, we don't even know when the user clicks a link (which is why file downloading is broken). When a php file is retrieved from the server, the server sends content-type: text/html so mozilla goes, "hey, I know how to handle this!" but on your local machine, windows doesn't send that so mozilla has no choice but to look at the extension. when you open a file with file->open or drag-drop, kmeleon tells mozilla, "this is an html document"

is this related to the EBay cgi problem?

Interesting... What's strange is that Mozilla itself does handle these links just fine (I'm talking about using the whole (bloated but hella sweet) browser itself, not just the Gecko engine, I know that confuses a lot of people sometimes, myself included) so it seems there'd be something set up in Mozilla either to take care of recognizing that file, or simply just dumbly opening the file and trying to handle it as text/html regardless, or on that tangent opening the file as text/html unless it recognizes a file header that says otherwise (hint hint, this sounds like a good approach, hint hint). I have no clue whatsoever as to which approach Mozilla uses, so I guess it's up to you guys to figure out. I'd help if I could, but unfortunately I'm just about useless when it comes to coding anything other than Java.

Perhaps looking at the Mozilla source itself and patching it to fix this bug in K-Meleon without affecting compatibility with the "normal" Mozilla is the way to go. I doubt the maintainers would mind having a bug in Mozilla's internals destroyed for them.

By the way, aside from the bugs (what new project doesn't have them anyway?) this browser flat-out rocks. It actually starts up faster than IE 5 on my system, despite the supposedly seamless integration into win2k. Ahh, the wonders of clean code. Great job guys.

Scratch, this problem only appears when opening files locally, as opposed to sending a request to a web server. I'm sure it's possible that the bugs are related, but I personally doubt it. Would be nice if were just one bug though, wouldn't it?

I understand that, but I still think they're related. When viewing pages locally you aren't getting a mimetype sent, and the ebay problem seems to be that it is getting the wrong mimetype sent, as far as I can tell.