K-Meleon

K-Meleon 1.5 Development


Latest Builds

K-Meleon 1.5b2 (Build 26, 2008-05-29, Forum)

  • Update 2 (2008-06-19): some minor fixes affecting localization (includes Update 1)
  • Update 1 (2008-06-04): this is a security relevant fix for the Preferences panel

K-Meleon 1.5b1 (Build 24, 2008-04-08, Forum)

K-Meleon 1.5a2 (Build 23, 2008-02-13, Forum)

K-Meleon 1.5a1 (Build 20, 2007-10-13, Forum)

  • Build 22 (2008-01-04): this build ditch the profile component and use something similar to firefox. (first step toward gecko 1.9, remove registry.dat annoyance (automatically imported in profiles.ini))
  • Build 21 (2007-12-01): Fortunately, most of the bugs fixed were trivial and easy to fix. The only major change is the addition of @TabList and @WindowList for the menus.



Current Bugs

  • Open a new page/tab and press Shift+Tabulator (maybe twice) => crash
    • FIXED (build 27)
  • The JSBridge plugin is broken since build 25, the service fails to initialize. (kko)
    • When the plugin is loaded and the service can be initialized correctly, there should be a button "Exceptions..." in section "Popup Blocker" in Preferences > Content Filters (just to give an example).
      • FIXED (build 27)
  • The cross on the close button of the find bar is looking strange.
    • FIXED (build 27)
  • Ad-blocking Style Sheet
    1. File adblock.css must be moved from defaults\settings to defaults\profile\chrome
      • Should have been FIXED in build 26 I think
        • Sorry. More precise: Has been fixed in the code, yes, but must also be moved on the file system level in the installation packages.
          • FIXED (build 27)
    2. The style sheet is applied only when it is enabled at runtime, not at startup.
      • Use the same behavior than flashblock, if one work the other one should too.
        • In theory :p
          • FIXED (build 27)
  • Up/Down Arrow keys in the URL Bar are not working correctly. In 1.1 (if I'm right) that allowed you to browse through the URL Bar History. Now it immediately loads the new URL, sometimes it just reloads the current page.
    • FIXED (build 27)
  • Homepage (reminder)
    • ID_NAV_HOME still using the old pref
      • FIXED (build 27)
    • When the old pref is not set, the window title is empty until the window is moved to the background. It disappears again when you open or close a tab.
      • FIXED (build 27)


Tab bugs/improvements

  • Unintentional duplication of the current tab (build 26, Win2k only)
    1. Right-click a tab button (to call the tab button menu), press Esc or left-click into the document (to make the menu disappear) and move the mouse cursor over a free space in the the tab bar => the previously right-clicked tab is duplicated (reopened in a new tab).
    2. Right-click a tab button (to call the tab button menu), then right-click onto a free space in the tab bar and keep the button pressed for an instant => the link symbol appears and the previously clicked tab is duplicated when the button is released (kko)
    3. FIXED (build 27)
  • kmeleon.tabs.fixedBar
    • seems to be ignored when kmeleon.tabs.bottomBar is true. This may not be desired when the Tab Bar is auto-hiding.
      • FIXED for 1.5b1 (build 24)
        • confirmed fixed (kko)
    • false
      1. Toolbars locked => tab bar unlocked (after a restart)
        • FIXED in 1.5b2 (build 26)
      2. browser.tabs.autoHide true and menu bar hidden => the first tab button is always elevated (hovered) when not pressed
        • In the meantime I have to say 'most often' instead of 'always'. I'm experiencing instabilities in this configuration (menu bar hidden). Sometimes the browser crashes or hangs at startup. Sometimes toolbars.cfg button bitmaps are not displayed (not always the same toolbar, but always all buttons of that toolbar were affected). May be related to the loader. I'm going to observe this further... (kko)
        • FIXED in 1.5b2 (build 26)
    • true
      1. Toolbars unlocked => tab bar stays locked (bug or feature?)
        • That's the point behind the fixed :p
      2. The Tab/Window Buttons seem to be assumed 16x16 pixels in size, bigger buttons are cut off.
        • Nah the bar grow accordingly but the buttons are misaligned for a mysterious reason. Since the favicon are always 16x16, probably not going to fix this soon.
      3. The Tab Bar title (kmeleon.tabs.title) is not displayed.
        • FIXED (build 27)
  • kmeleon.tabs.bottomBar at true (build 26)
    1. Open a new window (with only one tab) => The Tab Bar is displayed below the Status Bar.
      Open a second tab => The Tab Bar jumps on top of the Status Bar.
      • FIXED (build 27)
    2. Open a new window (with only one tab), open the Find Bar, then open a new tab => The Find Bar is displayed on top of the Tab Bar (OK)
      Now close the Find Bar and reopen it => The Find Bar is displayed below the Tab Bar
        • FIXED (build 27)
  • When loading a page in background, the loading icon stays visible behind the default/website icon when the page finished loading (until the tab is hovered or a new one is opened).
    • Never happened to me. Could be system specific, I may force a refresh if needed (dorian)
      • Depends on what icon you're using. When the loading icon is completely covered by the opaque parts of the default or website icon, you can't notice it of course. (kko)
    • Better in build 26. Still happens, but no clear pattern. (kko)
  • There is no right click context menu for items in the chevron drop down list (">>") and you can't drag'n drop an entry from there to some other place in the tab bar.
  • Tabs should be closed upon releasing the mouse button, not when starting the second click from the doubleclick (so you can keep the button pressed and move the mouse away to *not* close the tab) (ra, 2007-11-20).
    • The undo close make this VLP (Very Low Priority)
      • Isn't that just a matter of switching from mouseDown- to mouseUp-event? It's not only about undo close, but also usability - AFAIK all other browsers react on mouse button release.
        • no, I'm using the doubleclick event.
          • I still have problems getting used to it, but if no one else complains...
    • Fixed for middle click and right click (build 23)


Regressions from 1.1.x

  • There are disabled menu entries for tabbed browsing in the right click context menu on links (and on File and View menus as well). Why are they there at all in non-tabs mode? Please remove them if tabs are disabled - there are users that don't want to be bothered with tabbing stuff unfortunately...
    • We're still unsure on how we will handle that, maybe splitting the menu conf file.
      • What about not displaying disabled menu entries or exposing tabs as conditionals ("if tabs" the same way plugins can be checked, like "if macros")? (ra, 2007-11-20)
  • Locked menus are misaligned (buttons move to the left and leave space on the right, looks ugly compared to versions < 1.5, especially if you put several bars on the same row next to each other)
    • Not sure why but you have to resize the browser after locking/unlocking for them to realign correctly.
    • Dorian: That doesn't fix it (use a different skin than Phoenity). I think, the width of the toolbars has to be reduced when locking the toolbars (the grippy is then removed, but the space required for the grippy is not - at least not always). (kko)
      • There is another problem: button graphics overlapping the vertical line after locking (ra, 2007-11-20)
    • FIXED for 1.5a2
      • Still an open issue with build 21. (ra)
        • There is no difference in behavior compared to IE
          • There is one: IE(7, don't have IE6 anymore) doesn't move the toolbars if you lock them. Please compare the current situation with K-M 1.1 and prior and revert to the way it was.
            • It does. Check the menu bar and the links toolbar. The rest are not real toolbars in IE7.
              • Okay, the menu bar moves. But the Links toolbar doesn't move at all, just the grippy is removed. Great, but there seems to be some logic behind it: Button(-bar)s don't move when they are locked, menus do. %-)
      • Can't say that I had noticed any difference in build 21. Can't say either that I liked the behavior of pre-1.5 versions better. The question is how do we expect "Lock Toolbars" working? Maybe we should discuss that first, before chasing Dorian back and forth? (kko)
        • Have a look at the upper left part of the screenshots here: km11 vs. km15 The primary part that I don't like there is the space on the right of the button when a new bar follows. Please also note the the close button on the far right side automatically moves somewhat to the left when the window is maximized, although it can't be placed further to the right when the toolbars are unlocked. -- I propose a homogeneous layout with bars that keep their positions when you choose to lock the bars. There are some buttons a user might want to keep on the left and some on the right side, so it's difficult to decide where to move the bars if you don't add logic to move to the left if the bars start <50% width of the window and to the right if they are placed >=50%of the window...
          • The bars doesn't move. The buttons just reclaim the space used by the gripper. Preventing this is not something I can really do. If I do what you say, one of the toolbar will end up with all the extra space. But how can I know what bar it should be? Previous behavior was a bug, and it wasn't really consistent since new behavior could be triggered after some manipulation. (dorian)
        • Try the following (build 22). Unlock your toolbars, open about:config, enter "band" into the filter bar and reset all user-set kmeleon.toolband.<...>.size prefs. Close km and open <kmDir>\defaults\pref\skin.js. Comment out all kmeleon.toolband.<...>.size prefs except
          kmeleon.toolband.Menu.size and
          kmeleon.toolband.URL Bar.size.
          Set those to 1400 (or even higher). Now restart km and lock/unlock your toolbars. As long as you don't move/resize any toolbars, the locking/unlocking is then working how I would expect it. That is to say, the button toolbars (those defined in toolbars.cfg) are just as wide as necessary (non-greedy). The others are always as wide as possible (greedy). (kko)
          (Also try it with all ...size prefs in skin.js commented out. There is a noticeable difference between the locked and the unlocked URL Bar.)


Macro bugs

Please report macro issues in the Bugs Forum (kko)


Other bugs

  • The gestures plugin doesn't work on Windows Vista (build 22, don't know about previous versions/releases), the rocker gesture e.g. doesn't go back/forward, but the context menu pops up.
    • WFM, maybe try without aero (dorian)
      • Works without Aero. But with default settings (Aero on) it doesn't, even normal clicks won't work sometimes when gestures are on. (ra, 2008-02-28)
  • Toolbar background missing (black & partly transparent) when K-M is still running when you connect through remote desktop and usual login one after another. Looks like this: http://xs124.xs.to/xs124/08065/runningthroughnightremote325.png (build 22).
    • I confirm, but since kmeleon doens't do any drawing you can't blame it for this bug. As a workaround you can disable the background bitmap.
      • What can be blamed then? ;-) I haven't noticed this problem in any other app so far (and there are several skinned ones around) and I think it didn't happen with previous versions. (ra, 2008-02-28)
        • KMeleon only use the toolbar background used by IE. Maybe there are case where it need to be refreshed, but that's just weird.
  • Is "Resume" really working with downloads? I had a download that stalled, so I clicked on "Pause", waited a second and clicked "Resume" - but there was no reaction at all, neither on the download nor the connection visible. (Closing the browser and restarting it and starting the download again led to a successful download.)
    • There are 2 methods called pause and resume. I'm just using them ;+)) This work like firefox pause/resume.
    • Resuming paused downloads works for me. (kko)
      When a download is stalling, it's because the server is too busy or isn't responding anymore at all. Obviously, you cannot resume the download when the server isn't responding...
      • Well, you can resume if the server was just down for a second, the download stalled for some other reason (but the server is reachable in general) or your connection broke away. But in all these cases you can't resume the download with K-M. That makes this feature kind of useless, because you have to start the download again manually (and it will process fine then) cancelling the initial download ... (ra, 2007-11-20)
    • Dorian: Why is the Pause/Resume feature only offered when you choose to "open" a download?
      • What do you mean? Just saved something and pause/resume was working.
        • :p Forget about it. Found something else:
    • Start a download, pause it, then cancel it. Try to start the download anew.
      AFAICT, the connection is kept alive while the download is paused. Cancelling the paused download, doesn't terminate the connection however. When you try to restart the download, km indicates being busy, but nothing happens. (kko)
      • FIXED for 1.5a2 (build 21)
        • Should it be fixed for a stalled download or connection loss while downloading, too?
          • ra, from my point of view, you are mixing up two different things (kko):
            1. You are talking about HTTP Resume, as it is known from download managers. Km (i.e. Gecko) supports that as well. When a download is interrupted, all you can do is closing the download dialog and starting the download anew. Km can read the downloaded part of the file out of its cache and can automatically continue the download where it was interrupted, provided the server allows that.
            2. The purpose of this new pause/resume button is just pausing a download temporarily in order to gain bandwidth for something else. While paused, the connection to the server is kept alive. Once this connection is interrupted, you cannot resume the download - not with the pause/resume button. The purpose of this button is not forcing HTTP Resume!
          • The button should be able to handle both scenarios. Normal users won't know about it and blame K-M for not resuming their downloads (like a download manager would do), although they hit the button to do so after (e.g.) a connection loss. -- Please note that if I had to decide which feature to add, I'd personally go for HTTP Resume (or re-downloading the whole thing if HTTP Resume is not supported) and not pause/resume. Dorian decides, but please consider the fact that having a Resume-button that does absolutely nothing in all the scenarios described would certainly be a doubtful feature, because "true" resume (HTTP resume/redownloading) would be lacking.
          • The usefulness of this new feature is out of question to me. You simply misunderstood its purpose. In order to avoid such misunderstandings, I suggest to simply rename the button from Resume to Continue. Then this feature is less likely to be mixed up with HTTP Resume. (kko)


Old bugs


Difficult to reproduce bugs

  • Core/Gecko: K-M's sometimes stalling. It's just doing nothing for several seconds (20-30), no progress while loading pages in any window visible (and no data transfer either!), and then it progresses fine. It might happen only if one of the windows is a page with many many small thumbnails, that K-M is loading quite slowly, but it most likely seems to happen when a page is not responding. (One not responding site is hanging the whole browser.)
    • I've observed this too with km 1.1a3/b1 accessing our forum. When the SF/Chongqed logo hosting servers aren't responding, the browser seems to be locked, the GUI is not responding. I could reproduce the exact same behavior in SeaMonkey 1.1.1.
      Confirmed - SeaMonkey/Gecko bug (kko)
      • Will that still be a problem with KM1.5?
        • Look like it. KM still hang some time, and I'm unable to find where.
        • Mmm my case was different I guess. For me it happens after browsing a site with java. This can be incredibly annoying (freeze 2-3 seconds after each page load). (dorian)
      • There seems to be a similar problem with many tabs open: If you click on a link and/or open a new tab the browser is unresponsive until the site actually begins to load(mmh, make that render?), with K-M pausing for 2-3 seconds inbetween.


Improvement wishes of currently new 1.5 features

  • Better command registration, with a way to get the list of available command.
  • Add more gecko event (to improve macro functionnality)
  • Skin support png & zip
  • More gestures for gesture plugin, like first left then right and first up then down gestures (Hao Jiang, 2008-01-21)
  • Sessions plugin
    • Make the drop-down menus in the options dialog multi-line (5 or so), single-line is inconvenient.
    • Delete kmeleon.plugins.sessions2.<session>.count togther with the session.
      • FIXED in 1.5b2 (build 26)


Improvement wishes of older features

  • Please remember a proxy's username and password. Currently users have to re-enter the username and password every time the browser is started. (ra, 2007-11-20)
    • How does kmeleon ask for username & password? No checkbox to remember password?
      • The usual prompt appears, username & pwd. can be saved, but they are not remembered (might be related to the fact that I'm sometimes prompted to enter the data while the browser is still open, so I'm not 100% sure what's to blame). BTW: The site name is only displayed as "", but the url is correct. -- I'd favor a pref for proxy's credentials like other browsers handle it.
        • I'm afraid kmeleon can't do much for this, probably the password manager is not doing its work (or you have several password stored for the same domain, or maybe because it's empty). Kmeleon just display what gecko ask for. Any way for me to test it? (just to be sure)
          • Is there no way to store the data for the proxy with Gecko aside from the usual password manager? I'm afraid I don't know a proxy to test it, as the one I'm having the problem with is a corporate proxy that's not accessible from the Internet.
            • I don't think so, I wouldn't even know for what domain I should save it. :-\
              • Too bad. ;-( It's a bit annoying that you always have to either hit return (username&password remembered) or enter username&password every time the browser is started again. Firefox remembers the credentials somehow and doesn't ask for them all the time (only when the proxy re-asks for them I think).



Invalid bugs (won't fix / no fix needed / ...)


Tab bugs/improvements

  • kmeleon.tabs.useLoadingTitle seems to be ignored. The loading title is always displayed.
    • Only displayed until kmeleon get the page title (dorian)
      • Sounds logic, indeed. So, no bug. (kko)


Regressions from 1.1.x


Other bugs

  • If you enter s.th. in a text box while a cookie prompt is open you'll write right to left... (just noticed that, dunno about 1.1)
    • A know bug with Gecko 1.8 with modal dialog in general, there is a know workaroud for it but I've never implemented it because nobody ever complained about it.


Old bugs

  • Favicon transparency issue with http://xs209.xs.to/xs209/06472/favicon.png e.g. (black background instead of transparent), because "they use a 2bpp transparency bitmap, which is not supported by window. Which mean I have to convert it to a 4bpp image.".
    • Not sure if I can fix that one -- Dorian.


Difficult to reproduce bugs



Verified fixed bugs (won't be checked any further)


Tab bugs/improvements

  • With a certain number of open tabs (grow them one by one) the last tab is displayed twice 1) at the end of the tab bar and 2) as the first (and only) item in the chevron drop down list (">>") on the right.
    • FIXED for 1.5a2 (build 23)
  • Right-click a tab button (to call the tab button menu), then right-click somewhere else (outside the tabbar) => the tab button menu pops up again (kko)
    • FIXED for 1.5a2 (build 23)
  • Bookmark groups (nick-names) should be opened in background *tabs* if tabs are *on* (not background windows like in 1.5a1/2) and in background windows if tabs are off -- or there should be a setting... (ra, 2007-11-20)
    • That's the purpose of kmeleon.general.opengroup
      • Okay, so kko, how about toggling that one when tabs are enabled/disabled?
        • FIXED for 1.5a2
  • Please highlight the current tab item in the drop down list that appears on the right (">>") if you have too many tabs open, just like the current tab in the the tab bar.
    • FIXED for 1.5a2 (build 21)
      • Confirmed as fixed in build 21 with a checkmark. (ra)


Regressions from 1.1.x

  • Build 23: A click on the loader icon in the tray does no longer open a new browser window when there is already a window open. (kko)
    • Same when double-clicking k-meleon.exe.
    • FIXED for 1.5b1 (build 24)
  • Missing substitute for kmeleon.plugins.layers.rebarBottom (kko)
    • FIXED for 1.5a2 (build 23)
  • Build 22: I'm missing the cross on the close button of the find bar (kko)
    • FIXED for 1.5a2 (build 23)
  • Build 22: The new profile component seems to have a problem with the -P command line switch (haven't tried -profilesDir). When I have an instance running and want to start a new one using "-new -P", I always get a warning that the profile was in use. But the profile I've specified in the command line isn't in use. (kko)
    • FIXED for 1.5a2 (build 23)
  • Using type ahead find pressing F3 doesn't take you to the next result anymore, but opens the Search-prompt (instead).
    • 'Search-prompt' meaning 'Find Bar' (kko)
    • FIXED for 1.5a2 (build 22)
  • Missing substitute for layers() in menus (list of current tabs) (kko)
    • FIXED for 1.5a2 (build 21 add @TabList)
  • Macros plugin: setmenu(...,where) with where=0 seems to work like where=-1 (the item is added at the end of the menu, not at the beginning) (kko)
    • is it a setmenu() only issue? (ie settings.cfg is not affected?) (dorian)
      • no, position index has generally no effect in menus.cfg (items are always added at the end of the menu);
        labels and commands are working correctly in both setmenu() and menus.cfg (kko)
        • FIXED for 1.5a2 when 0 is used for position in setmenu(). The rest didn't change since 1.1


Other bugs

  • The browser doesn't remember its previous window size (maximized in my case, tabs are off) on startup and when using "undo last closed window". In the last case the opened window has the status maximized while it covers only a third of the screen, so you first have to restore it (to the exact same size) in order to correctly maximize it.
    • More exact (kko):
      1. kmeleon.display.maximized ignored at startup. (Bug 966)
        • Look like it works for me
          • Found a weird behavior of windows. maybe FIXED for 1.5a2
            • OPEN in build 21 (close browser maximized and start it again => not maximized)..
              • Look fine for me. Could be OS related?
                • I observed the same behavior under 2k and XP. (kko)
                  Make sure you don't start with a session!
                  • FIXED for 1.5b1 (build 24)
      2. Window state "maximized" is not correctly restored for saved sessions when the current window is maximized. The middle window button in the title bar indicates "maximized", but the window itself isn't. Maybe this is already resolved when sessions are opened in addition to the current window...
        • FIXED for 1.5a2 (build 21)
  • Whenever s.th. is saved (save image as, save file as, ...) a kme*.tmp file with 0 KB is "added" in the %temp% folder (build 22 currently).
    • FIXED for 1.5a2 (build 23)
  • Preferences-wise tabs have to be activated before they can be deactivated
    • FIXED in 1.5a1 update 1 (kko)
  • With browser.urlbar.autocomplete.enabled set to false, the browser crashes when pressing Ctrl+Tab/Ctrl+Shift+Tab if the URL bar has the focus. (kko)
  • Text in cookie prompt partly broken: "The site ... wants to set a cookie" - instead of the site's name there are only "boxes" visible (Unicode character problem?). The details shown below the text work.
    • FIXED for 1.5a2
      • Confirmed as fixed in build 21. (ra)


Old bugs

  • Local files with umlauts or accents in the path name fail to open in external applications (external source code editor and apps called through macros). (kko)
    Such characters are double-escaped (%??%??) in km's URL. Most Windows apps fail to interprete this correctly (e.g. IE and Notepad).
    • External source code editor:
      1. Convert "file:///c:/folder/name.ext" paths into "c:\folder\name.ext" paths given in the local Windows character set.
        • FIXED for 1.5a2 (build 21)
      2. Remove any trailing "?..." and "#..." components.
        • FIXED for 1.5a2 (build 22)
    • Macros:
      The exec() statement suffers from the same problem. I guess, we need an urldecode() function?
      • FIXED for 1.5a2 (build 22)
  • Keyword Autosearch doesn't work when Typed URLs are set to open in a new tab (kmeleon.general.openurl = ID_OPEN_LINK_IN_NEW_TAB) or background tab (kmeleon.general.openurl = ID_OPEN_LINK_IN_BACKGROUNDTAB). Same in 1.1 with layers. (kko)
    • FIXED for 1.5a2 (build 21)


Difficult to reproduce bugs

  • Probably Macros Plugin: The save as directory is not always remembered. With numerous windows open (windows only mode), changing the directory in one window doesn't always change it for the others. It doesn't matter whether page load is still in progress or finished. Works correct when there are no kmms loaded (macros plugin disabled or main.kmm absent). Not caused by kmm code. Could not reproduce it yet, can't say anything about layers. Report (kko)
    • Haven't had this problem with 1.5a2 yet. Was there some change that might related to it? (ra)
      • Too much to tell :)
        • Confirmed as fixed (ra)
  • The first bookmark or favorite opened after startup is sometimes opened in a new background window, although the browser is configured to open it in the current window. It works like it is supposed to for subsequent items.
    • Can't reproduce currently
    • Can't reproduce either (kko)
      • Mmh, can you try again, the bug's there. And possibly related: With tabs on only the first bookmark of a bookmarks group is opened when you first try it (enter the nick in the url bar). When you open the group again (enter the nick again) the other bookmarks are opened, too; but in background windows - I suppose they should be opened in background tabs when tabs are on. (ra, 2007-11-20)
      • More exact: Disable tabs, restart the browser (just to make sure). Open a page and open several links from that page in new background windows. Now open a bookmark. => The bookmark will load in the last window opened in the background overwriting the page that was loading there, instead of the current page. If you open the bookmark again in a different window it will load in this window like it is supposed to do.
      • FIXED for 1.5a2 (build 21)
        • Confirmed as fixed in build 21. (ra)


Improvement wishes of older features

  • A chevron drop down list for the menu bar would be nice if the menu is partly hidden by button bars.
    • FIXED for 1.5a2 (build 22)
K-Meleon

(c) 2000-2010 kmeleonbrowser.org. All rights reserved.
design by splif.